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:
ACTIONSOURCEDESTINATIONPROTOCOLPortForward
DNAT2.2.2.25.5.5.5fifty172.30.0.254
DNAT2.2.2.25.5.5.551172.30.0.254
DNAT2.2.2.25.5.5.5udp500172.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)
ACTIONSOURCEDESTINATIONPROTOCOLPortForward
DNAT2.2.2.25.5.5.5udp500172.30.0.254∗00
DNAT2.2.2.25.5.5.5udp4500172.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

Also popular now: