The following list contains some additional configuration concerns
for NAT traversal:
- When using NAT traversal, z/OS® views
its own address as the one configured in the z/OS home list. If the z/OS host is behind a NAT, this address is a
private address. Otherwise, it is the public address of the z/OS host.
The z/OS implementation does not use private addresses
in its configuration to describe the remote IKE peer or remote IP
connection endpoint. z/OS views
its IPSec peer and the remote IP connection endpoint as a public IP
address. If a NAT is in front of the IPSec peer, the z/OS host perceives the IPSec peer and connection
endpoint addresses to be that of the NAT.
- For IKEv1 Security Associations, you should not configure pre-shared
keys in Main mode when multiple remote peers are behind a NAT and
the peers do not map to unique RemoteSecurityEndpoint specifications.
RFC 3947 states that pre-shared keys cannot be used with Main mode,
unless group shared keys for all those behind the NAT are deployed.
The use of group pre-shared keys is considered a security risk.
- If a NAT address is coming out of a dynamic NAT pool, addresses
assigned to a host from the pool can be assigned any of the pooled
addresses. In this case, there are additional considerations. When z/OS is the responder, the IPSec
policy intended for a host must be broad enough to cover the entire
range of IP addresses in the dynamic NAT pool. When z/OS is the initiator and the responder is behind
a NAT, the identity of the target host can be ambiguous. Do not configure
a z/OS host to initiate to
an ambiguous target host.
- When a remote security endpoint is behind a NAT, its identity
must be unique. During a phase 1 negotiation, the remote security
endpoint sends its identity in an ID payload. The IKE daemon can manage
multiple remote security endpoints using the same ID when those endpoints
are not behind a NAT. However, when a remote security endpoint is
behind a NAT, it must use a unique IKE identity.
- When the remote security endpoint is a security gateway behind
a NAT or a host behind a NAPT, only TCP, UDP, and ICMP traffic is
supported. ICMP traffic has limited support.
- z/OS allows traffic for
a TCP connection to continue as long as the integrity of the connection
can be verified. Two cases where z/OS can
no longer verify the integrity of the connection are:
- Adding or removing IPSec protection for a TCP connection
When
a TCP connection traverses a NAT, the TCP connection must be restarted
after a filter policy change that causes the connection's traffic
to change from IPSec-protected traffic to clear text, or from clear
text to IPSec-protected traffic.
- NAT IP address remapping
If the peer's IP address is remapped
by a NAT due to a timeout or reboot of the NAT device, the TCP connection
must be restarted.