Steps for configuring the branch office with NAT model (host-to-gateway with IPSec)

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

Similar to branch office model, but a NAT device is added in front of security gateway of branch office.

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:
1. Configure a key exchange policy that defines the parameters of the phase 1 negotiation as follows:
  1. 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.
  2. 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.
  3. 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
}
```
  4. 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.
  5. 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.
  6. Configure a KeyExchangeAction statement as follows:
```
KeyExchangeAction            Gold-PSK
{
  HowToInitiate              main
  HowToRespondIKEv1          main
  KeyExchangeOfferRef        SHA1-AES-PSK
}
```
  7. 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
}
```
  8. 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
}
```
  9. Include the KeyExchangeRule statement in the KeyExchangePolicy statement block, as follows:
```
KeyExchangePolicy
{
    AllowNat                   Yes
    KeyExchangeRuleRef         ZoneC_KeyExRule1
}
```
2. Configure an IpDynVpnAction statement defining the control of the phase 2 negotiation, as follows:
  1. 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.
  2. Determine whether tunnel or transport mode is required.
    Tunnel mode is required when one of the security endpoints is a security gateway.
  3. 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
}
```
  4. 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.
  5. 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
}
```
3. Decide how the Security Association is activated.
  1. 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.
  2. 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
}