Report this

What is the reason for this report?

Strongswan site-to-site VPN with NAT

Posted on February 7, 2022

I want to establish a tunnel connection to a remote site that uses IPSec. For the remote site I have:-

  • Gateway IP
  • Encryption domain IP

For the client site (My site). I provided:-

  • Gateway IP (My droplet public IP)
  • Encryption Domain IP (My droplet floating IP). The remote site requires my encryption domain be Public IP.

I managed to configure strongswan and establish tunnel connection but no traffic flow. When I tcpdump traffic passing through UDP port I get the following.

  • 16:13:28.954685 IP 161.35.236.X.4500 > 41.222.182.X.4500: NONESP-encap: isakmp: phase 2/others ? inf[E]

I did PREROUTING and POSTROUTING for incoming and outgoing traffic:-

sudo iptables -t nat -I PREROUTING 1 -s 41.222.176.X/32 -d 137.184.245.X/32 -j DNAT --to-destination 10.124.0.X
sudo iptables -t nat -I PREROUTING 1 -s 41.222.182.X/32 -d 137.184.245.X/32 -j DNAT --to-destination 10.124.0.X
sudo iptables -t nat -I POSTROUTING -s 10.124.0.X/32 -d 41.222.176.X/32 -j SNAT --to-source 137.184.245.X
sudo iptables -t nat -I POSTROUTING -s 10.124.0.X/32 -d 41.222.182.X/32 -j SNAT --to-source 137.184.245.X

Below is my ipsec.conf file:-

config setup
        charondebug="all"
        uniqueids=never

conn %default
        type=tunnel
        authby=secret
        auto=start
        keyexchange=ikev1
        dpdaction=restart
        closeaction=restart
        keyingtries=%forever
	ike=aes256-sha1-modp1024!
        esp=aes256-sha1!
        ikelifetime=86400s
        lifetime=3600s
	forceencaps=yes
	left=%defaultroute
        leftid=10.124.0.X
        leftsubnet=137.184.245.X/32   
        right=41.222.182.X

conn test
        rightsubnet=41.222.176.X/32

conn live
        rightsubnet=41.222.176.X/32

conn rend-1
        rightsubnet=41.222.182.X/32

conn rend-2
        rightsubnet=41.222.182.X/32

conn rend-3
        rightsubnet=41.222.182.X/32

How can I get traffic to flow with this setup or what did I do wrong?

Many thanks for your assistance!



This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Hi there,

From what you’ve shared, the tunnel itself is coming up, so IKE and IPsec negotiation look fine. The issue is likely that the traffic never matches the IPsec policies, so it never enters the tunnel.

The main problem seems to be the combination of NAT and traffic selectors. You are advertising a public IP as leftsubnet, but the actual traffic is coming from a private IP (10.124.0.X). If the source and destination don’t match leftsubnet and rightsubnet, StrongSwan will not encrypt the packets, regardless of NAT rules.

In most site to site IPsec setups, you should avoid NAT on traffic that is meant to be encrypted. IPsec needs to see the original source and destination to match the selectors. Using DNAT and SNAT here is very likely preventing traffic from flowing.

I would start by making leftsubnet match the real internal IP or subnet, remove NAT for IPsec traffic, and verify that rightsubnet matches what the remote side expects. Once traffic flows, only add NAT back if the remote side explicitly requires it.

Heya, @ombenikimaro

Your main issue is that you’re mixing identities and subnets. You tell the peer your encryption domain is the public floating IP (137.184.245.X/32), but you set leftid to a private IP (10.124.0.X). If the remote side expects the public IP, both leftid and leftsubnet need to line up with that public address.

At minimum, try:

  • leftid=137.184.245.X

  • leftsubnet=137.184.245.X/32

  • Collapse the multiple conn entries into one and list all rightsubnets there

Then make sure traffic is SNATed to 137.184.245.X before it hits IPsec, and check the usual Linux gotchas: enable net.ipv4.ip_forward=1 and disable or loosen rp_filter. When those don’t match, you get exactly what you’re seeing: phase 2 up, no traffic.

The developer cloud

Scale up as you grow — whether you're running one virtual machine or ten thousand.

Get started for free

Sign up and get $200 in credit for your first 60 days with DigitalOcean.*

*This promotional offer applies to new accounts only.