Need help with strongSwan config on LEDE, please!

Greetings, I am setting up strongSwan on LEDE 17.01.4 for a net-to-net connection. I have the key exchange working with IKEv2 and the SA is established. I'm having a lot of problems getting the packet exchange working after about a week of banging around on it.

The best/most current recipe I have found has a comment to turn off libipsec, which I believe should help since it was having loading problems (maybe related to this problem).

What I am not seeing is any ESP traffic at all. My /etc/ipsec.conf:

config setup
#    charondebug="ike 3"

conn handy

I used the firewall configuration from that first article, but I think I have problems because the ipsec devices are no longer used when libipsec is turned off in strongSwan:

config zone
        option forward 'REJECT'
        option name 'vpn'
        option output 'ACCEPT'
        option network 'ipsec'
        option input 'ACCEPT'

config rule
        option src 'wan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option src 'wan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config rule
        option target 'ACCEPT'
        option src 'wan'
        option proto 'udp'
        option dest_port '4500'

config rule
        option target 'ACCEPT'
        option src 'wan'
        option proto 'ah'

config forwarding
        option dest 'lan'
        option src 'vpn'

config forwarding
        option dest 'wan'
        option src 'vpn'

config forwarding
        option dest 'vpn'
        option src 'lan'

I'm confused where to go from here. It seems like if I want to let strongSwan use the default route interface, instead of a tunnel device (which I wasn't able to get working either), I need to know more, but I'm not sure what.

Any help appreciated! Hopefully this will help others once it's worked out. i found this maybe this will help.

Thanks @sycohexor, that's the best document I have seen yet on what's going on beyond configuration. It caused me to recall something I had never checked well, the contents of routing table 220. As it turns out in my case, the table is empty. Here is respective status command output:

root@LEDE:~# ip route list 220

root@LEDE:~# ip rule list
0:	from all lookup local 
220:	from all lookup 220 
32766:	from all lookup main 
32767:	from all lookup default 

root@LEDE:~# ipsec statusall
no files found matching '/etc/strongswan.d/*.conf'
Status of IKE charon daemon (strongSwan 5.5.3, Linux 4.4.92, armv7l):
  uptime: 13 minutes, since Nov 05 14:10:31 2017
  worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
  loaded plugins: charon test-vectors ldap pkcs11 aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt af-alg fips-prf gmp curve25519 agent xcbc cmac hmac ctr ccm gcm curl mysql sqlite attr kernel-netlink resolve socket-default connmark forecast farp stroke smp updown eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls xauth-generic xauth-eap dhcp whitelist led duplicheck addrblock unity
Virtual IP pools (size/online/offline): 2/0/0
Listening IP addresses:
       handy:  IKEv2
       handy:   local:  uses pre-shared key authentication
       handy:   remote: [] uses pre-shared key authentication
       handy:   child: === TUNNEL
Security Associations (1 up, 0 connecting):
       handy[1]: ESTABLISHED 10 minutes ago, yyy.yyy.178.6[yyy.yyy.178.6][]
       handy[1]: IKEv2 SPIs: f85446b32fb04885_i* 40f5460cb70b669d_r, pre-shared key reauthentication in 32 minutes
       handy[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
       handy{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cfa7470a_i cd25c79f_o
       handy{1}:  AES_CBC_256/HMAC_SHA2_512_256, 0 bytes_i, 0 bytes_o, rekeying in 4 minutes
       handy{1}: ===

In /etc/strongswan.conf, I have added install_routes = yes.

Even if there was a firewall issue, I would have expected the routes to be installed after the SA was established.

Is there anything I can do with the ESP SPIs (for instance, see their contents)? Any additional input or resources that have helped others much appreciated!

Not sure if this is helpful but I to had routing problems with a StrongSwan tunnel.
I didn't use zones

I ended up using a specific route to reach my destination.

iptables -t nat -I POSTROUTING -s -d -j ACCEPT

1 Like

Trying to get IPsec site-to-site configs working with any xxxswan packages on openWRT/LEDE can be a headache since the documentation is always falling behind the sliding window of development which itself is not always documented. It's taken me a certain time-investment to figure out how to get this stuff working. There is no proper GUI part which takes care of all of this for you. Why? Because anyone who has reached the point of installing strongswan to do IPsec should understand enough of IP and routing to be able to do things manually. But the documentation for this stuff is not all in one easy place.

So, basically, LEDE 17.01.04:

opkg update
opkg install strongswan-full
#you may also need to add the following packages if you for some reason opt for strongswan-minimal
# and your certificates are in text/base64 format: --- BEGIN blah ---
opkg install strongswan-mod-pem strongswan-mod-pkcs1

The strongswan-full package notes: "...all of the strongswan plugins except kernel-libipsec..." so there are no vti adaptors installed, no ipsec adaptors, and no kernel mods doing any magic for you. This means you don't need to go do stuff like "goez to za network and installz ipsec0 inturfejs now lolz!"

Add your certificates/private-keys to the respective folders in /etc/ipsec.d/ and reference the certs in the /etc/ipsec.conf file conn entries.


conn blah

Then reference the private-key halves in /etc/ipsec.secrets


Now IKE is all set.

So you run ipsec restart and ipsec statusall and if everything was done correctly until now, you see as you have that your connection is up and Security Associations (1 up, 0 connecting)

If you go to status -> firewall, ( /cgi-bin/luci/admin/status/iptables ) you will see the firewall rule that ipsec adds at the top of each of the INPUT/FORWARD/OUTPUT tables with a comment under the options column like: policy match dir out pol ipsec reqid 1 proto 50.

But you ping a host in the remote subnet and watch as your ping traffic just disappears out onto the WAN connection. What happened? The packet for the VPN has to leave the LAN, and exit the WAN interface before it can get encrypted and sent down the tunnel. But all packets leaving the LAN going to the WAN get NATed according to all of the general firewall rules. Dafuq.


So go to network -> firewall -> custom rules (which is still probably only filled with #comment lines). Simply add the following and click restart firewall below the box:

iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT


General NAT problems
Local firewall stacks generally don't treat packets with a matching IPsec policy any different from unprotected packets. That means, that any NAT rules also apply to traffic that is supposed to be tunneled.

This often leads to problems, because many hosts have SNAT or MASQUERADE rules set up, which change the source IP of the packets and make the packets not match the negotiated IPsec policies when IPsec processing of outgoing packets happens (In the graphic here that's "xfrm lookup").
The general solution to that is to except all packets with a matching IPsec policy from NAT in the POSTROUTING chain of the nat table. This is achieved by inserting a rule that accepts packets with a matching IPsec policy before any NAT rule in the POSTROUTING chain.

The following rule does that:

iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT

caveat: if you add or modify rules specific to traffic between your local and remote subnets, and apply them in the firewall, your firewall IPsec magic might stop working, in which case re-run "ipsec restart" so the ipsec tool re-inserts its rules into iptables again.

You should also see under the NAT POSTROUTING table, a row with an options column comment of policy match dir out pol ipsec which corresponds to our manual command inserted earlier in firewall.user.

I have not found a more convenient way of doing this in the GUI, which actually works and sticks. firewall.user is it.

Did anyone successfully created VTI for IPsec, if yes then please let me know