VPN with NAT-Traversal

I'm going to talk about an issue that arise when you are trying to setup Remote Access VPN for devices behind the NAT/PAT. For the IPsec tunnel to be negotiated, first there is an ISAKMP connection has to be established. It uses UDP on port 500. That means, that PAT device must be configure with port forwarding to VPN device on UDP port 500. That is about ISAKMP. When both ISAKMP phases are negotiated and ISAKMP connection are established, it's time to establish IPsec tunnel. Let's assume, that we are using ESP encapsulation for our IPsec. ESP is a network layer protocol, os it doesn't contain any layer 4 headers with port numbers. But somehow PAT device has to translate these connections. It is done through using of NAT-Traversal or IPsec over TCP. NAT-Traversal encapsulate ESP packet in a UDP header with destination port 4500. So to get VPN working, we have to configure port forwarding on our PAT device with redirection of both UDP port 500 and 4500. The same thing can be accomplished with IPsec over TCP, but with IPsec over TCP we have an ability to change ports on with our tunnels will be established.

P.S. AH can't be used along with PAT devices on it's way, because MD5 hash that it generates, include IP headers, which means, that changing them will completely brake the hash and the packet will be discarded on recieving device. For example, ESP doesn't calculate hash of the whole packet. Instead, it calculate it for payload only. So ESP is a protocol of my choice. Why do someone should use AH these days anyway?

Split tunneling defines what traffic from the user must go across the tunnel and what traffic can leave the client in clear text. Split tunneling policies are defined with the split-tunnel-policy command. The default split-tunneling policy is tunnelall, which means that, with the exception of DHCP and ARP packets, all traffic from the remote must go across the tunnel. You can exclude networks from being tunneled (excludespecified parameter) or include networks that should only be tunneled (tunnelspecified parameter). When overriding the default split tunneling policy, you must use the split-tunnel-networklist command to specify what destination networks are (tunnelspecified) or are not tunneled (excludespecified). These are defined in an extended or standard ACL. For a standard ACL, the addresses or networks you enter are addresses that the remote is trying to reach (destination addresses). For an extended ACL, the addresses off of the higher-level interface of the appliance (corporate office networks) are the source addresses in an ACL statement, and the destination addresses are the internal addresses of the remotes.

Sounds stupid. I should test it.