It is still quite common to connect when the provider puts its router and gives the client private addresses. To be able to build an IPsec tunnel through a similar connection, NAT Traversal (NAT-T) was invented. At one time, I spent a lot of time realizing what needs to be specified as local and remote hosts at the ends of the tunnel in OpenSWAN. Who is interested in this topic, welcome under cat.
I carried out all the tests on the stand, having assembled the following configuration:

In this case, the task is to build an IPsec tunnel between FW1 and FW2, while FW1 has a private address on the WAN interface - 172.30.0.254 and is located behind the provider’s router.
Immediately, I’ll make a reservation that there are several conditions for this and it all depends on the possibility of setting up the provider’s router:
')
Option 1:
ACTION | SOURCE | DESTINATION | PROTOCOL | PORT | FORWARD |
---|
DNAT | 2.2.2.2 | 5.5.5.5 | 50 | | 172.30.0.254 |
DNAT | 2.2.2.2 | 5.5.5.5 | 51 | | 172.30.0.254 |
DNAT | 2.2.2.2 | 5.5.5.5 | udp | 500 | 172.30.0.254 reduce00 |
That is, all packets with an outgoing address 2.2.2.2 and with a destination address 5.5.5.5 via UDP protocol coming to port 500 redirect to 172.30.0.254 (this is our FW1) also to port 500. And do the same thing with all packets using protocols 50 and 51 (ESP and AH respectively).
This is not NAT-T, actually the usual IPsec works this way. The problem is that this method can “earn” or “not earn”, and no one can give guarantees (this largely depends on the provider), therefore it is advised to use the second option.
Option 2: NAT Traversal (NAT-T)
ACTION | SOURCE | DESTINATION | PROTOCOL | PORT | FORWARD |
---|
DNAT | 2.2.2.2 | 5.5.5.5 | udp | 500 | 172.30.0.254 reduce00 |
DNAT | 2.2.2.2 | 5.5.5.5 | udp | 4500 | 172.30.0.254:4500 |
As you can see, only the UDP protocol is used here, which is allowed by default on most providers.
How to install and configure OpenSWAN, on Habré wrote more than once, for example,
here , therefore I will give just examples of configurations.
For FW1:
/etc/ipsec.conf nat_traversal = yes
protostack = netkey
conn connection_to_fw2
type = tunnel
auto = start
authby = secret
pfs = yes
ike = aes256-sha1; modp2048
phase2 = esp
phase2alg = aes256-sha1; modp2048
left = 172.30.0.254
leftnexthop = 172.30.0.1
leftsourceip = 192.168.0.1
leftsubnet = 192.168.0.0 / 24
leftid = @ left
right = 2.2.2.1
rightsubnets = 10.0.0.0 / 24
rightid = @ right
For FW2:
/etc/ipsec.conf nat_traversal = yes
protostack = netkey
conn connection_to_fw1
type = tunnel
auto = start
authby = secret
pfs = yes
ike = aes256-sha1; modp2048
phase2 = esp
phase2alg = aes256-sha1; modp2048
right = 2.2.2.1
rightid = @ right
rightsourceip = 10.0.0.1
rightsubnet = 10.0.0.0 / 24
left = 5.5.5.1
leftid = @ left
leftsubnet = 192.168.0.0 / 24
leftnexthop = 172.30.0.1
Both sides should have the
same key entry:
@left @right: PSK "123456789"
Well, the version of Openswan:
ipsec --version
Linux Openswan U2.6.37 / K3.2.0-83-generic-pae (netkey)Restart OpenSWAN and check:
/etc/init.d/ipsec restartroot @ fw2: ~ # ifconfig
eth0 Link encap: Ethernet HWaddr 00: 0c: 29: cd: 12: 76
inet addr: 10.0.0.1 Bcast: 10.0.0.255 Mask: 255.255.255.0
root @ fw2: ~ # ping -I eth0 192.168.0.1
PING 192.168.0.1 (192.168.0.1) from 10.0.0.1 eth0: 56 (84) bytes of data.
64 bytes from 192.168.0.1: icmp_req = 1 ttl = 64 time = 0.577 ms