Configuring OpenSWAN IPsec PSK using NAT Traversal (NAT-T)
- Tutorial
Connection is still very common when the provider sets up its router and issues private addresses to the client. 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 understanding what needs to be indicated as local and remote hosts at the ends of the tunnel in OpenSWAN. Who cares about this topic, welcome to cat.
I conducted all tests at the stand, collecting this 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 make a reservation that there are several conditions for this and it all depends on the ability to configure the provider’s router:
Option 1:
That is, all packets with an outgoing address 2.2.2.2 and with a destination address 5.5.5.5 using UDP protocol should be redirected to port 500 to 172.30.0.254 (this is our FW1) also to port 500. And the same thing should be done with all packets using protocols 50 and 51 (ESP and AH, respectively).
This is not NAT-T, in fact, this is how ordinary IPsec works. The problem is that this method can “earn”, or it can “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)
As you can see, only the UDP protocol is used here, which is enabled by default for most providers.
How to install and configure OpenSWAN, they wrote more than once on Habré, for example, here , so I’ll just give examples of configurations.
For FW1:
/etc/ipsec.conf
For FW2:
/etc/ipsec.conf
both sides must have the same key entry:
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 restart
root @ 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
I conducted all tests at the stand, collecting this 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 make a reservation that there are several conditions for this and it all depends on the ability to configure the provider’s router:
Option 1:
ACTION | SOURCE | DESTINATION | PROTOCOL | Port | Forward |
---|---|---|---|---|---|
DNAT | 2.2.2.2 | 5.5.5.5 | fifty | 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∗00 |
That is, all packets with an outgoing address 2.2.2.2 and with a destination address 5.5.5.5 using UDP protocol should be redirected to port 500 to 172.30.0.254 (this is our FW1) also to port 500. And the same thing should be done with all packets using protocols 50 and 51 (ESP and AH, respectively).
This is not NAT-T, in fact, this is how ordinary IPsec works. The problem is that this method can “earn”, or it can “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∗00 |
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 enabled by default for most providers.
How to install and configure OpenSWAN, they wrote more than once on Habré, for example, here , so I’ll just give 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 must 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 restart
root @ 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