📜 ⬆️ ⬇️

Configure OpenSWAN IPsec PSK using NAT Traversal (NAT-T)

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:
ACTIONSOURCEDESTINATIONPROTOCOLPORTFORWARD
DNAT2.2.2.25.5.5.550172.30.0.254
DNAT2.2.2.25.5.5.551172.30.0.254
DNAT2.2.2.25.5.5.5udp500172.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)
ACTIONSOURCEDESTINATIONPROTOCOLPORTFORWARD
DNAT2.2.2.25.5.5.5udp500172.30.0.254 reduce00
DNAT2.2.2.25.5.5.5udp4500172.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 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

Source: https://habr.com/ru/post/259479/


All Articles