The branch office with NAT model modifies the branch office
model topology to include a NAT in front of the security gateway.
Before you begin
The following NAT implications for host-to-gateway dynamic
IKE negotiations are covered in the discussion of this model:
- Local and remote data endpoints
- Local and remote security endpoints
- IKE initiator and responder roles
- Restriction on HowToAuth protocol (AH not supported)
Steps for configuring the branch office model: Part 1 (host-to-gateway with IPSec) assumed
a network topology with both the host and the security gateway, as
well as the hosts behind the security gateway, using public IP addresses.
Often one or both security endpoints are behind a NAT using a private
IP address.
Modifying the branch office model topology to include
a NAT in front of the security gateway, the branch office with NAT
topology becomes as shown in Figure 1:
Figure 1. Branch office with NAT model
This example will describe the configuration considerations
and requirements when the NATT solution is implemented to traverse
NAT devices in a host-to-security gateway environment. The branch
office with NAT model has the same basic security requirements as
the branch office model. Configuration statements added or changed
for the branch office with NAT model are shown in bold.
The example describes the policy for host 9.3.3.3.
For this
example, assume the following requirements to enable network communications
from zone C, a branch office network using private IP addresses (10.3.0.0/16),
to a public IP address (9.3.3.3) on this host. The hosts on the branch
office network connect to the Internet through the branch office gateway
server, which is behind a NAT. In this model, the NAT has a static
mapping of the security gateway's private address 10.3.3.3 to the
public address 9.5.5.5.
- Allow IKE traffic from the branch office zone C security gateway
to this host.
- Allow EE traffic from branch office zone C to an EE service running
on this host, using a dynamic VPN with strong authentication and encryption.
Only one host behind the security gateway (branch office zone C) will
be able to send EE traffic.
Guideline: In
most cases, EE hosts should not be located behind a security gateway
that is behind a NAT. Instead, a host-to-host Security Association
should be negotiated for each EE host.
In Steps for configuring the branch office model: Part 1 (host-to-gateway with IPSec), the
VPN was brought up when the z/OS® stack
initialized by setting the AutoActivate parameter to Yes on the LocalDynVpnRule
statement. In this scenario, the hosts behind the gateway do not have
public addresses that can be configured in the policy. Therefore,
initiation from host 9.3.3.3 to the security gateway 9.5.5.5 becomes
ambiguous because the IP address of the remote data endpoint is unknown. z/OS does not allow initiation
of a UDP-encapsulated tunnel mode Security Association to a security
gateway. The Security Associations between the security gateway 9.5.5.5
and host 9.3.3.3 must be initiated by the security gateway, with host
9.3.3.3 acting as responder.
- Allow normal FTP traffic from branch office zone C to an FTP server
running on this host, using a dynamic VPN with strong authentication
and encryption. In Steps for configuring the branch office model: Part 1 (host-to-gateway with IPSec), the
VPN was activated by an administrator from the z/OS UNIX command
line. Again, z/OS does not
allow initiation of a UDP-encapsulated tunnel mode Security Association
to a security gateway. The Security Associations between the security
gateway and host 9.3.3.3 must be initiated by the security gateway,
with host 9.3.3.3 acting as the responder.
- Peers authenticate themselves using the pre-shared key method.
Procedure
Perform the following steps to meet these requirements
and configure the branch office with NAT model.
- Determine the number of zones to be protected. The
branch office represents one zone, zone C.
- For each zone, determine what services are allowed and
define an IpService block for each wanted service. Services
are defined by their protocols and the well-known ports that they
use.
The definitions that describe FTP traffic can be combined
in an IP service group. Typically, FTP clients use passive mode (PASV)
or extended passive mode (EPSV) to connect to the FTP server when
the client is behind a NAT. For more information on active and passive
mode FTP, see Considerations for IPSec-encapsulated FTP traffic when traversing a NAT.
The
range of server ports specified for the data connection reflects the
port range specified for PASSIVEDATAPORTS in the server's FTP.DATA
file. For more information on PASSIVEDATAPORTS, see z/OS Communications Server: IP Configuration
Reference.
The following definitions show the
services required for the server for PASV or EPSV:
IpServiceGroup FTPServer
{
IpService FTPServer-Control
{
SourcePortRange 21
Protocol tcp
Direction bidirectional InboundConnect
Routing local
SecurityClass 0
}
IpService FTPServer-Data-Passive
{
SourcePortRange 50000 50200
Protocol tcp
Direction bidirectional InboundConnect
Routing local
SecurityClass 0
}
}
The traffic pattern for Enterprise Extender can be
defined in one IpService block as follows:
IpService Enterprise-Extender
{
SourcePortRange 12000 12004
DestinationPortRange 12000 12004
Protocol udp
Direction bidirectional
Routing local
SecurityClass 0
}
- Determine the data endpoints to be protected. In
this example, for the local host public IP address, 9.3.3.3, define
the following statement:
IpAddr PublicServerAddressA1
{
Addr 9.3.3.3
}
In this case, the remote data endpoints are in the
branch office's internal network. The z/OS NATT
implementation does not require the coding of private addresses for
the remote endpoints. Instead, the security gateway's public address
is treated as the remote data endpoint. The NAT is using a static
mapping for the security gateway, so the public address of the gateway
is specified. If the NAT was using dynamic mappings, the range of
public IP addresses to which the security gateway could be mapped
would need to be included in this definition.
IpAddr BranchOfficeGateway
{
Addr 9.5.5.5
}
This IP address is also needed to permit IKE traffic
between the local public server and the remote branch office gateway.
- Determine what level of security is needed between each
set of data endpoints. In this example, strong authentication
and encryption is needed for both EE and FTP traffic, so ESP authentication
and ESP encryption are used. ESP must be used when NAT traversal support
is being used.
- Configure an IpGenericFilterAction statement for the level
of security that is required (permit, deny, ipsec), including whether
the connection should be logged, as follows:
IpGenericFilterAction ipsec
{
IpFilterAction ipsec
}
- If IPSec is required between any two endpoints, take the
following actions:
- Configure a key exchange policy that defines the parameters
of the phase 1 negotiation as follows:
- Determine the required type and strength of protection for the
phase 1 Security Association.
In this example, SHA1 authentication
is used because it is more secure than MD5, and AES encryption is
used because it is as secure as 3DES.
- Decide what type of peer authentication to use.
In this example,
pre-shared key authentication is specified in the requirements. Typically,
the RSA signature method is preferable, given its numerous advantages,
but for the purposes of example the pre-shared key method is used
here. Because there is only one remote IKE peer in the branch office
scenario (the remote security gateway), and because it is relatively
simple to configure, pre-shared key authentication is a reasonable
choice.
- Configure a KeyExchangeOffer statement that defines the parameters
for the phase 1 negotiation as follows:
KeyExchangeOffer SHA1-AES-PSK
{
HowToEncrypt AES_CBC KeyLength 128
HowToAuthMsgs SHA1
HowToAuthPeers PresharedKey
DHGroup Group14
}
- Decide whether NAT traversal will be allowed.
The AllowNat
parameter on the KeyExchangePolicy and KeyExchangeAction statements
enables the IKED to advertise NAT traversal support. For this model,
allow NAT traversal support to be advertised for all phase 1 Security
Associations by specifying Yes on the AllowNat parameter on the KeyExchangePolicy
statement:
AllowNat Yes
For
this model, use the NatKeepAliveInterval parameter default value,
20 seconds. When z/OS is behind
a NAT, a NAT keep-alive timer is started, with the interval specified
in NatKeepAliveInterval parameter on the KeyExchangePolicy statement.
Because z/OS is not behind
a NAT in this model, a NAT keep-alive is not kept regardless of the
value specified or the default for NatKeepAliveInterval.
- Determine the negotiation mode, Main or Aggressive.
Because
security is a priority in the branch office with NAT model, the more
secure Main mode is used for the phase 1 negotiation.
- Configure a KeyExchangeAction statement as follows:
KeyExchangeAction Gold-PSK
{
HowToInitiate main
HowToRespondIKEv1 main
KeyExchangeOfferRef SHA1-AES-PSK
}
- Configure a LocalSecurityEndpoint statement and RemoteSecurityEndpoint
statement as follows:
LocalSecurityEndpoint Public_IKED
{
Identity IpAddr 9.3.3.3
LocationRef PublicServerAddressA1
}
RemoteSecurityEndpoint ZoneC_IKED
{
Identity Fqdn gateway.BO.example.com
LocationRef BranchOfficeGateway
}
- Configure a KeyExchangeRule statement that includes the two endpoints
and the key exchange action, as follows:
KeyExchangeRule ZoneC_KeyExRule1
{
LocalSecurityEndpointRef Public_IKED
RemoteSecurityEndpointRef ZoneC_IKED
KeyExchangeActionRef Gold-PSK
PresharedKey abracadabra
}
- Include the KeyExchangeRule statement in the KeyExchangePolicy
statement block, as follows:
KeyExchangePolicy
{
AllowNat Yes
KeyExchangeRuleRef ZoneC_KeyExRule1
}
- Configure an IpDynVpnAction statement defining the control
of the phase 2 negotiation, as follows:
- Determine the required type and strength of IPSec protection for
the phase 2 Security Association.
In this example, authentication
is ESP HMAC_SHA1 and encryption is AES.
- Determine whether tunnel or transport mode is required.
Tunnel
mode is required when one of the security endpoints is a security
gateway.
- Configure an IpDataOffer statement that defines the parameters
of the phase 2 negotiation, as follows:
IpDataOffer SHA-AES-Tunnel
{
HowToEncap tunnel
HowToEncrypt AES_CBC KeyLength 128
HowToAuth ESP HMAC_SHA1
}
- Determine which peer is allowed to initiate the negotiation.
In
this scenario, the hosts behind the gateway do not have public addresses
that can be configured in the policy. Therefore, initiation from host
9.3.3.3 to the security gateway 9.5.5.5 becomes ambiguous because
the IP address of the remote data endpoint is unknown. z/OS does not allow initiation of a UDP-encapsulated
tunnel mode Security Association to a security gateway. The Security
Associations between the security gateway 9.5.5.5 and host 9.3.3.3
must be initiated by the security gateway, with host 9.3.3.3 acting
as responder.
- Configure an IpDynVpnAction statement that defines the control
information for the phase 2 negotiation, as follows:
IpDynVpnAction Gold-TunnelMode
{
Initiation remoteonly
InitiateWithPfs group2
AcceptablePfs group2
IpDataOfferRef SHA-AES-Tunnel
}
- Decide how the Security Association is activated.
- Only remote initiation of the Security Association is allowed,
as specified for the Initiation parameter on the Gold-TunnelMode IpDynVpnAction
statement. No LocalDynVpnRule or IpLocalStartAction statements are
needed.
- Create an IpFilterRule statement that allows IPSec traffic (ESP),
or set the global IpFilterPolicy statement parameter PreDecap to off.
In
this example, PreDecap off is used in the IpFilterPolicy
statement.
- Define an IpFilterRule statement for each set of data endpoints. The rule should include the services that are allowed (one IpService
statement for each allowed service), and the level of security that
is required (a reference to the IpGenericFilterAction statement).
If IPSec is required, create an IpFilterRule statement that allows
IKE traffic (UDP, port 500 and 4500). See the IpAddr and IpAddrSet
statements configured previously.
IpFilterRule Rule1C
{
IpSourceAddrRef PublicServerAddressA1
IpDestAddrRef BranchOfficeGateway
IpServiceRef IKE-local-500
IpServiceRef IKE-local-4500
IpGenericFilterActionRef permit
}
IpFilterRule Rule2C
{
IpSourceAddrRef PublicServerAddressA1
IpDestAddrRef BranchOfficeGateway
IpServiceRef Enterprise-Extender
IpServiceGroupRef FTPServer
IpGenericFilterActionRef ipsec
IpDynVpnActionRef Gold-TunnelMode
}
- Define an IpFilterGroup statement for each zone and include
the IpFilterRule statements that belong to that zone.
- Include all IpFilterGroup references and, optionally, any
additional IpFilterRule statements as needed, in the IpFilterPolicy
block.
- Include all configured statements in the stack-specific
IP security configuration file.
Results
The following policy is the complete IP security policy
for traffic from the local secure server to zone C, assuming that
the reusable statements are included in the common IP security configuration
file:
#-------------------------------------------------------
# Filter Policy for Secure Server
#-------------------------------------------------------
IpFilterPolicy
{
PreDecap off
FilterLogging on
AllowOnDemand no
IpFilterGroupRef ZoneC
}
#-------------------------------------------------------
# KeyExchange Policy for Secure Server
#-------------------------------------------------------
KeyExchangePolicy
{
AllowNat Yes
KeyExchangeRuleRef ZoneC_KeyExRule1
}
########################################################
# Connectivity Profile
# Secure Server To Zone C
#
# Server to Trusted Branch Office Network
#
########################################################
IpFilterGroup ZoneC
{
#-------------------------------------------------------
# Permitted Zone C traffic:
# Allow IKE traffic from the gateway IKE Server
# for branch office to this host.
#
# IKE (UDP port 500/4500) - IKE negotiations
#-------------------------------------------------------
IpFilterRule Rule1C
{
IpSourceAddrRef PublicServerAddressA1
IpDestAddrRef BranchOfficeGateway
IpServiceGroupRef IKE
IpGenericFilterActionRef permit
}
#-------------------------------------------------------
# IPSec-protected Zone C traffic:
#
# Enterprise Extender (ports 12000-12004)
# FTP Server - SubnetC to PublicServerAddressA
#-------------------------------------------------------
IpFilterRule Rule2C
{
IpSourceAddrRef PublicServerAddressA1
IpDestAddrRef BranchOfficeGateway
IpServiceRef Enterprise-Extender
IpServiceGroupRef FTPServer
IpGenericFilterActionRef ipsec
IpDynVpnActionRef Gold-TunnelMode
}
}
KeyExchangeRule ZoneC_KeyExRule1
{
LocalSecurityEndpointRef Public_IKED
RemoteSecurityEndpointRef ZoneC_IKED
KeyExchangeActionRef Gold-PSK
PresharedKey abracadabra
}