Network Address Translation traversal support
This chapter describes the support for an IP Security (IPSec) tunnel that traverses a Network Address Translation (NAT) or Network Address Port Translation (NAPT) device.
The chapter offers a high-level overview of NAT and NAPT, explains why NAT and NAPT pose problems for IPSec, and describes support for IPSec tunnels that traverse a NAT or NAPT device.
This chapter describes the solution to these problems and demonstrates the support in our environment by showing configuration examples.
|
Tip: z/OS Communications Server provides NAT traversal support only for IPv4 traffic.
|
This chapter includes the following topics
11.1 Network Address Translation
Network Address Translation (NAT) is a method defined in RFC 3022. NAT, as the name suggests, is a way of translating (or changing) a host’s source IP address into a different IP address on an outbound packet. To allow two-way communications, the same translation is performed on an inbound packet. Thus, a NAT device acts as a router between two networks with the ability to translate IP addresses and ports. When connecting two separate networks, there will be a designated inside and outside network. Generally, NAT devices will perform port translation as well.
With the increase of Internet addresses worldwide, it is becoming more difficult for enterprises to assign globally unique IP addresses to each host. There simply are not enough unique IP addresses to ensure secure and accurate data transmission from site to site or company to company. By using NAT, a single worldwide Internet address can be used to represent a large private network. As a result, NAT devices are fast becoming a way for large, multisite enterprises to avoid IP address conflicts.
A second benefit is one of security: by using NAT, the real IP address assigned to a host is hidden from the Internet. By hiding the real IP address of a host, it becomes more difficult to access or harm the host behind the NAT device.
NAT itself provides a simple IP address conversion table between a private IP address and a public IP address. After the IP address conversion is done, IP checksum and TCP checksum are recalculated and updated.
NAT encompasses the following IP mapping techniques:
•One-to-one address translation (static or dynamic NAT)
•Network Address Port Translation (NAPT)
11.1.1 One-to-one NAT
An internal-external IP address mapping is maintained by the NAT device. IP addresses are translated, but ports are unchanged. The mapping can be static or dynamic. For a static mapping, there is a definition in the NAT that always translates IP address x.x.x.x to IP address y.y.y.y. An outbound packet is not needed to establish the mapping. For a dynamic mapping, the NAT has a pool of IP addresses that are assigned as needed. Therefore, IP address x.x.x.x might be mapped to IP address y.y.y.y one time, and to IP address z.z.z.z at another time. The mapping is established when an outbound packet is processed. Figure 11-1 shows static NAT.
Figure 11-1 Static NAT
11.1.2 Network Address Port Translation
The Network Address Port Translation (NAPT) technique uses multiple internal IP addresses that are translated into a single public IP address. As part of this translation process, the TCP and UDP ports in the packets are translated. NAPT is sometimes referred to as port address translation (PAT) or IP masquerade.
The mapping is typically dynamic and established in the NAPT when an outbound packet is processed. For example, the NAPT might create a mapping for internal address x.x.x.x port y to external address a.a.a.a port b, and a mapping for internal address z.z.z.z port v to external address a.a.a.a port c. When only one client behind a NAPT has negotiated a security association, it is not always possible for the remote peer to detect whether the public address is being used for one-to-one address translation or for NAPT.
When multiple clients have active security associations, the remote peer can detect when port translation is being performed. The terms “in front of” and “behind” are used to convey which IP address a NAT is translating. When a NAT is said to be in front of a client, it means that the client’s address will be translated by the NAT. When a server is said to be behind a NAT, it means that server’s address will be translated by the NAT.
|
Tip: NAPT translation is by far the most commonly found Network Address Translation. It is implemented in most home-use firewall and router devices. Quite often, the term NAT is used when in fact the term NAPT should be used. It is common enough that the term NAT is considered to be synonymous with NAPT in everyday usage.
In this chapter we distinguish these two terms, when appropriate.
|
In our NAPT configuration example that is shown in Figure 11-2, clients communicate with a TELNET server through a NAT router. All clients are communicating with only one address called the inside global address as displayed in the router’s NAT table. This registered IP address is used by users who come from the public network to reach the z/OS TELNET server in the private network.
Figure 11-2 NAPT configuration example
Example 11-1 shows the results from the corresponding z/OS Netstat Telnet display command for the client connections to port 23 on the z/OS TELNET server.
Example 11-1 z/OS Telnet display
Internal Telnet Server Status:
Conn State BytesIn BytesOut ApplName LuName
---- ----- ------- -------- -------- ------
00009902 Establsh 0000000032 0000000739 SC31TS02
Foreign socket: ::ffff:192.168.1.251..3905
00009900 Establsh 0000000032 0000000739 SC31TS01
Foreign socket: ::ffff:192.168.1.254..3145
11.2 IPSec and NAT incompatibilities
This section describes incompatibilities between IPSec and NAT functions.
Inherent incompatibilities exist between IPSec and NAT functions. RFC 3715, IPSec-Network Address Translation (NAT) Compatibility Requirements, provides a description of the problems that arise when IPSec is used to protect traffic that traverses a NAT.
One basic problem is that when IPSec security associations traverse a NAT, the NAT is unable to update IP addresses and checksums that are part of the encapsulated data (encrypted, authenticated, or both). RFCs 3947, 3948, and 5996 define mechanisms that enable specific uses of IPSec to traverse one or more NAT devices.
•RFC 3947, Negotiation of NAT Traversal in the IKE, allows an Internet Key Exchange (IKE) daemon to detect when one or more NATs are being traversed.
•RFC 3948, UDP Encapsulation of IPSec ESP Packets, defines two IPSec encapsulation modes: UDP-Encapsulated-Tunnel mode, and UDP-Encapsulated-Transport mode. These modes facilitate the traversal of IPSec traffic through a NAT by encapsulating ESP packets within a UDP packet.
•RFC 5996, Internet Key Exchange Version 2 (IKEv2) Protocol, defines the IKEv2 protocols. Section 2.23 NAT Traversal specifies how to detect when IKEv2 peers are traversing one or more NATs. It also describes how UDP encapsulation of IKE and ESP packets is used to allow IPSec to interoperate with NAT when using IKEv2.
UDP-Encapsulated-Tunnel mode and UDP-Encapsulated-Transport mode security associations are negotiated by IKE when NAT traversal is enabled and a NAT is detected. Manually configured security associations do not support UDP-Encapsulated-Tunnel mode or UDP-Encapsulated-Transport mode.
The NAT traversal support, as defined by the Internet Engineering Task Force (IETF), transmits internal IP addresses to its IPSec peer. These internal addresses are not exposed on the external network. However, the internal addresses are available for display at the remote security endpoint. If you are considering using this support, evaluate whether transmitting internal IP addresses to an IPSec peer is acceptable from a security policy perspective.
|
UDP encapsulation: UDP encapsulation is not encapsulating a UDP packet. UDP encapsulation is inserting a UDP header between the IP header and the ESP or IKE header. The payload data can have a TCP, UDP, or other transport header.
|
11.3 NAPT traversal support for integrated IPSec/VPN
z/OS Communications Server extends IP security support to protect traffic that traverses a NAPT device. This device translates multiple internal IP addresses to a single public address, and translates the TCP or UDP port to make the connection unique. There are inherent incompatibilities between IPSec and NAT functions. Problems occur when IPSec is used to protect traffic that traverses a NAT or NAPT device. NAT traversal support as defined by the IETF in RFC 3947 (Negotiation of NAT traversal in the IKE), RFC 3948 (UDP encapsulation of IPSec ESP packets), and RFC 5996 (IKEv2 section 2.23) defines mechanisms that allow specific uses of IPSec to traverse one or more NAT or NAPT devices. IP security provides NAT traversal support for a defined group of configurations where an IPSec security association (SA) traverses a NAPT device.
Restrictions
In configurations where the remote security endpoint is behind a NAPT device, the following SA restrictions exist:
•The remote security endpoint must initiate the SA.
•The remote data endpoint must initiate the data.
•Only TCP, UDP, and Internet Control Message Protocol (ICMP) traffic is supported. ICMP traffic has limited support.
•In a sysplex-wide Security Association (SWSA) environment, the SA can be distributed only to targets at release level V1R8 or later that have IP security configured between IPv4 addresses.
•If a UDP-encapsulated mode SA is negotiated using the IKEv2 protocol, then the SA and the connections over the SA are distributed to only a V1R12 or later target.
•In an SWSA environment, SWSA takeover functions are not available for the SA.
11.3.1 Enabling NAPT traversal support for IPSec
The objective was to successfully establish an IPSec dynamic tunnel from a Windows client, through a Router NAPT device to a TELNET server running on the z/OS mainframe. To test and verify the support, we made the following configuration changes:
•IBM Configuration Assistant: Enabled NAT traversal support for TCPIPA
•Router: Configured NAT and Port Address Translation (PAT) for port 23
•Windows XP: Installed and configured IPSec
Our test environment is shown in Figure 11-3.
Figure 11-3 NAPT traversal test environment
Next, we describe the configuration changes we made to our test environment to successfully establish the IPSec dynamic tunnel using the NAPT traversal device.
IBM Configuration Assistant changes
This section describes the other changes that are required on the IBM Configuration Assistant GUI to enable the NAPT support.
|
Important: Before making these changes, refer to and complete the IPSec for Windows XP implementation using the examples that are supplied in Appendix C, “Configuring IPSec between z/OS and Windows” on page 859 as a guide.
|
To make changes in the IBM Configuration Assistant, complete the following steps:
1. From the main IBM Configuration Assistant panel, select Stack - TCPIPA in the Navigation tree, as shown in Figure 11-4. Click the Stack Settings tab.
Figure 11-4 TCP/IP stack settings
2. On the Stack Settings page, select Allow NAT, Enable filter logging, and Do NOT log implicit deny events (see Figure 11-5). Click Advanced Settings.
Figure 11-5 IPSec: Stack level settings
This option enables NAT keepalive messages, as shown in Figure 11-6.
Figure 11-6 NAT keepalive settings
3. Click the Rules tab, as shown in Figure 11-7. Select or highlight the rule for 10.10.1.241 to 192.168.1 253, click Select Action. Click Modify.
Figure 11-7 TCP/IP Connectivity Rules
4. In the Modify Connectivity Rule panel, click the Additional Settings tab. Click Advanced (see Figure 11-8).
Figure 11-8 Connectivity Rule: Additional Settings
5. Click the Key Exchange tab. Next to Network Address Translation (NAT) traversal, select Allow, as shown in Figure 11-9.
Figure 11-9 IPSec: Dynamic Tunnels: Key Exchange Settings
6. Click OK until the IPSec Navigation Tree is displayed. Click the small symbol to the right of Stack - TCPIPA and select Install Configuration Files, as shown in Figure 11-10.
Figure 11-10 Install Configuration Files selection
7. Transfer the new IPSec rules to the PAGENT server on z/OS by selecting the IP Security Policy clicking the Select option. Then, click Select Action → Install (see Figure 11-11).
Figure 11-11 Configuration Files installation
Router configuration
For our NAPT device, we used a router on which we configured a Static Port Address Translation (PAT) feature for ports 23, 500, and 4500. Apart from the normal Telnet port, 23, we also had to configure ports 500 and 4500 for the IKE and IPSec Dynamic tunnel. Our configuration is shown in Example 11-2.
Example 11-2 Router NAPT configuration
provrtr01#sh run
Building configuration...
Current configuration : 1409 bytes
!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname provrtr01
!
boot system flash c2600-ik9s-mz.122-15.t17.bin
boot system flash c2600-is-mz.122-11.t3.bin
logging queue-limit 100
enable secret 5 $1$1WC1$Vhn3KRUVOba5gobLe2Jbb.
enable password itsc
!
ip subnet-zero
!
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
ip nat outside
duplex auto
speed auto
!
interface Serial0/0
no ip address
shutdown
!
interface FastEthernet0/1
ip address 10.10.2.200 255.255.255.0
ip nat inside
duplex auto
speed auto
!
ip nat inside source static tcp 10.10.1.241 23 192.168.1.1 23 extendable
ip nat inside source static udp 10.10.1.241 500 192.168.1.1 500 extendable
ip nat inside source static udp 10.10.1.241 4500 192.168.1.1 4500 extendable
ip nat outside source list 1 interface FastEthernet0/1
ip http server
no ip http secure-server
ip classless
ip route 10.10.0.0 255.255.0.0 10.10.2.1
!
access-list 1 permit 192.168.1.0 0.0.0.255
!
snmp-server community public RO
snmp-server enable traps tty
call rsvp-sync
!
line con 0
line aux 0
line vty 0 4
password swj43r
login
!
!
end
Windows XP configuration
We completed the steps in this section after completing the initial Windows XP IPSec configuration that is described in Appendix C, “Configuring IPSec between z/OS and Windows” on page 859. However, because our IPSec tunnel traversed a NAT device, we also had to enable NAT traversal support for Windows. Therefore, we describe that process in this section.
|
Important: If these actions are not done, the IPSec NAT traversal tunnel will not establish successfully.
|
We had Windows XP Service Pack 2 installed, and because a change in the default behavior for Windows IPSec NAT traversal, we had to make a modification to the Windows Registry. Search for “NAT Traversal” on the Microsoft support website to determine whether your system requires similar changes. For more information about our change, see this website:
We also changed the Destination address as described in “Setting up a Windows IPSec policy for pre-shared key mode” on page 868 to reflect our Inside global IP address 198.168.1.1. This address corresponds to the IP address that was configured on Interface FastEthernet0/0 of the router device that is shown in Example 11-2 on page 544.
11.3.2 Testing and verification
To verify our configuration and the functionality of the IPSec NAT traversal support for NAPT, we established a Telnet connection from our Windows client 192.168.1.253 to the outside global address 192.168.1.1 port 23.
The outside global address in return gets translated by the PAT on the router to 10.10.1.241 port 23, which represent the z/OS server. This action created a dynamic IKE IPSec tunnel between the Windows client and the z/OS server, which confirmed the functionality of the IPSec NAPT traversal support.
The following steps provide relevant examples and descriptions of the snapshots that were taken during this verification stage after we successfully established the Telnet connection from the Windows client to the z/OS server:
1. The MSG10 on the client (Figure 11-12) was the first indication that we managed to establish the IPSec tunnel.
Figure 11-12 MSG10 on the Windows client
2. We logged on to the router and issued the show ip nat translation command. The output in 11.3, “NAPT traversal support for integrated IPSec/VPN” on page 539 confirmed the following important pieces of information:
– Our NAPT configuration was done correctly and performed as intended.
– Further confirmation that the IPSec tunnel was successfully established over the NAPT device. Port 4500 represents the IPSec dynamic tunnel.
Example 11-3 Router NAT display
provrtr01#sh ip nat translation
Pro Inside global Inside local Outside local Outside global
tcp 192.168.1.1:23 10.10.1.241:23 --- ---
udp 192.168.1.1:4500 10.10.1.241:4500 --- ---
udp 192.168.1.1:500 10.10.1.241:500 --- ---
udp 192.168.1.1:4500 10.10.1.241:4500 192.168.1.253:4500 192.168.1.253:4500
provrtr01#
c. On the z/OS server, we issued a Netstat Telnet command, which confirmed that we had a connection established on port (04147) with the Windows client. The port number corresponds with the port number displayed on the MSG10, as shown in Example 11-4.
Example 11-4 Netstat Telnet display on z/OS
Internal Telnet Server Status:
Conn State BytesIn BytesOut ApplName LuName
---- ----- ------- -------- -------- ------
00000130 Establsh 0000000032 0000000739 SC31TS01
Foreign socket: ::ffff:192.168.1.253..04147
***
3. From the z/OS OMVS shell, we issued the ipsec command to verify both the IKE and Dynamic tunnel. First, we issued the ipsec -p tcpipa -k command and then the ipsec -p tcpipa -y command. The results from these commands are shown in Example 11-5 and Example 11-6 on page 548, respectively.
Example 11-5 Output from the ipsec -p tcpipa -k display
Primary: IKE tunnel Function: Display Format: Detail
Source: IKED Scope: Current TotAvail: n/a
TunnelID: K1
Generation: 3
IKEVersion: 1.0
KeyExchangeRuleName: All_Traffic_DES~5
KeyExchangeActionName: All_Traffic_DES
LocalEndPoint: 10.10.1.241
LocalIDType: IPV4
LocalID: 10.10.1.241
RemoteEndPoint: 192.168.1.253
RemoteIDType: IPV4
RemoteID: 192.168.1.253
ExchangeMode: Main
State: DONE
AuthenticationAlgorithm: Hmac_Sha
EncryptionAlgorithm: DES
DiffieHellmanGroup 1
AuthenticationMethod: PresharedKey
InitiatorCookie: 0XEBFAC6490364F62A
ResponderCookie: 0XDA471394239D2C08
Lifesize: 0K
CurrentByteCount: 544b
Lifetime: 480m
LifetimeRefresh: 2006/08/16 15:05:08
LifetimeExpires: 2006/08/16 16:48:49
Role: Initiator
AssociatedDynamicTunnels: 1
NATTSupportLevel: D2RFC
NATInFrntLclScEndPnt: Yes
NATInFrntRmtScEndPnt: No
zOSCanInitiateP1SA: Yes
AllowNat: Yes
RmtNAPTDetected: No
RmtUdpEncapPort: 4500
Example 11-6 shows the output from the ipsec -p tcpipa -y display command.
Example 11-6 Output from the ipsec -p tcpipa -y display
Primary: Dynamic tunnel Function: Display Format: Detail
Source: Stack Scope: Current TotAvail: 1
TunnelID: Y2
Generation: 3
IKEVersion: 1.0
ParentIKETunnelID: K1
VpnActionName: DES
LocalDynVpnRule: n/a
State: Active
HowToEncap: Transport
LocalEndPoint: 10.10.1.241
RemoteEndPoint: 192.168.1.253
LocalAddressBase: 10.10.1.241
LocalAddressPrefix: n/a
LocalAddressRange: n/a
RemoteAddressBase: 192.168.1.253
RemoteAddressPrefix: n/a
RemoteAddressRange: n/a
HowToAuth: ESP
AuthAlgorithm: Hmac_Sha
AuthInboundSpi: 708956256
AuthOutboundSpi: 2506164033
HowToEncrypt: DES
EncryptInboundSpi: 708956256
EncryptOutboundSpi: 2506164033
Protocol: ALL(0)
LocalPort: 0
RemotePort: 0
OutboundPackets: 27
OutboundBytes: 3127
InboundPackets: 37
InboundBytes: 986
Lifesize: 0K
LifesizeRefresh: 0K
CurrentByteCount: 0b
LifetimeRefresh: 2006/08/16 11:54:38
LifetimeExpires: 2006/08/16 12:48:49
CurrentTime: 2006/08/16 08:53:27
VPNLifeExpires: 2006/08/17 08:48:22
NAT Traversal Topology:
UdpEncapMode: Yes
LclNATDetected: Yes
RmtNATDetected: No
RmtNAPTDetected: No
RmtIsGw: No
RmtIsZOS: No
zOSCanInitP2SA: Yes
RmtUdpEncapPort: 4500
SrcNATOARcvd: 0.0.0.0
DstNATOARcvd: 0.0.0.0
The examples in this section might change with each release. For more information, see the most recent version of z/OS CS: IP System Administrator’s Commands, GC31-8782.
Debugging tools
We used the following commands and tools to gather debugging information, depending on the type of problem on which we worked:
•TCP/IP Netstat, Ping, Tracerte, and displays
•Omproute (OSPF) d tcpip,tcpipa,omp,ospf,xxxxx displays
•Log files, MVS console log, and Syslogd
•2600 Router, show ip nat translations, debug ip nat detailed
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.