IP masquerade works well for TCP and UDP, but how about some more exotic IP protocols? Not that easy when it comes to IPsec VPNs. We need to connect to a customer's site that uses Contivity VPN from Nortel. This is an IPsec-based product. Unfortunately, masquerading several IPsec connection through one router is a non-trivial task that Linux is currently not capable of. IPsec connection involves a handshake over UDP, after which the data is transmitted over IP protocol 50 (Encapsulating Security Payload, ESP). Since there is no connection tracking support for IP protocol 50 in the Linux kernel, only one internal client can connect to a remote IPsec VPN server at any time, because the kernel cannot tell one connection from another. This was not acceptable to us, since we need several people to work with the customer's VPN simultaneously.
NAT Traversal feature of IPsec protocol is supposed to resolve this problem, however, for some reason, NAT Traversal didn't work with the customer's VPN server. Attempts to persuade the customer's IT personnel to look into the issue and enable NAT Traversal proved unsuccessful (they either didn't understand what the problem was, or didn't care, or both). We had to resolve the issue ourselves.
After some thought, the solution was found. First it involved getting several external IP addresses from our ISP, as many as many people we needed to work with the customer's VPN. Luckily, it wasn't many, just five. The idea then was to route the IPsec traffic from the five internal clients through separate external IP addresses. This will allow the kernel to keep track of each connection separately and not mix them up. Here's how I achieved this using iptables.
For the sake of example, I'll assume that our external IP numbers were 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52 and 184.108.40.206. All these numbers were bound to our external network interface as aliases. Assuming our external interface is called eth1, these new addresses were assigned to alias interfaces eth1:1, eth1:2, etc. up to eth1:5. Also for the sake of example, assume that the client computers that need to talk to the customer's VPN have internal IP addresses 192.168.1.1 - 192.168.1.5 and that the customer VPN server's address is 220.127.116.11.
With this setup, I added the following iptable rules to NAT table:
iptables -t nat -A POSTROUTING -s 192.168.1.1 -d 18.104.22.168 -j SNAT --to-source 22.214.171.124 iptables -t nat -A POSTROUTING -s 192.168.1.2 -d 126.96.36.199 -j SNAT --to-source 188.8.131.52 ... iptables -t nat -A POSTROUTING -s 192.168.1.5 -d 184.108.40.206 -j SNAT --to-source 220.127.116.11
This tells the kernel the following: right after routing (POSTROUTING chain), if the packet is coming from 192.168.1.x (a VPN client) to 18.104.22.168 (the VPN server), masquerade it using source address 1.1.1.x.
An important note is that these rules should precede the rules that masquerade the entire network. I have a rule like this:
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 -j MASQEURADEand it is added to the POSTROUTING change after the special rules above.
The above technique allows to masquerade multiple IPsec (or indeed any IP protocol) connections when NAT Traversal is not available. This said, I would much prefer if NAT Traversal worked and saved me the headache.