Configuration scenarios supported for NAT traversal

Communications Server can act as a host Security Association endpoint for UDP-encapsulated mode Security Associations that are negotiated to enable IPSec traffic to traverse a NAT. The partner company with NAT model and the partner company with NAPT model describe Communications Server's host-to-host support. The branch office with NAT model describes Communications Server's host-to-security gateway support.

Rule: Communications Server does not support acting as a security gateway endpoint for UDP-encapsulated tunnel mode Security Associations. This is different than the Communications Server support provided for tunnel mode Security Associations, where Communications Server can act as a security gateway, although Communications Server is not typically deployed in this manner.

The figures in the subtopics show z/OS® configuration support for UDP-encapsulated Security Associations. A Security Association is negotiated by two IKE peers, with one initiating the negotiation and the other acting in responder mode. The location of the NAT, and the NAT's functionality, affect which IKE peer can initiate the Security Association. A traditional dynamic NAT implementation requires outbound traffic to be sent first to create an address mapping, before inbound traffic can be accepted. The dynamic NAT can be creating one-to-one address mappings from a dynamic pool of public IP addresses, or creating many-to-one address port mappings using a single public IP address and a pool of port values. When an IKE responder is behind a NAT, the NAT's address mapping must be static, allowing inbound traffic for the address to be received prior to outbound traffic being sent.