Ipsec / Strongswan firewall configuration

georgh · October 15, 2018, 2:51am

I am running Openwrt 18.06.1 on a TP-Link AC 1750. Installed packages are strongswan-default, ipsec-tools.

I am trying to set up a VPN from the Openwrt (local) to a FritzBox (remote). The remote router has a dynamically assigned public IP address and is reachable via DynDNS. The local router is placed behind the provider - supplied FTTH - router in a dual stack lite / CGNAT setting. It is not reachable from the internet.

I have an implementation running with StrongSwan on a linux server, the main configuration problems (crypto parameters that work with the FritzBox, building the tunnel and keeping it alive from the local side...) are solved. porting the whole thing from the linux machine to the Openwrt router is the task at hand.

I tried to follow the dokumentation (user's guide) and ran into inconsistencies between doku and reality at several points:

several packages required by "ipsec Basics" are not available: ip, djbdns, strongswan-utils.
"ipsec Firewall" suggests setting up the firewall rules from the uci / Luci framework without using direct iptables rules. The text addresses a couple of issues related with creating the rules through Luci, and refers to a script "firewall.ipsec" that takes care of these issues.
I could not find this script. There is a printout in the doku which is useless, it includes another script "functions.sh" which is also missing.

Questions:

is the script "firewall-ipsec" obsolete?
are the missing packages renamed, or is their functionality provided b other packages?
Is there any chance to set up the firewall following the documented approach?

Any suggestion is welcome,
Georg

vgaetera · October 15, 2018, 6:16am

Obviously, if nobody updates the guide, it becomes outdated.

JW0914 · October 15, 2018, 11:59am

IPsec VPNs are fairly obsolete due to the lack of features and tuning they offer. An SSL VPN [OpenVPN] would likely be the better way to go, unless there's a specific reason you're needing an IPsec VPN

mikma · October 15, 2018, 12:24pm

In what way is IPsec lacking features?

Edit: I don't think IPsec with IKEv2 lacks any important features. It can't use TCP as transport, but TCP over TCP is a bad idea anyway. Why TCP Over TCP Is A Bad Idea.

JW0914 · October 15, 2018, 12:36pm

Please utilize your search engine of choice.

georgh · October 15, 2018, 1:52pm

@vgaetera: thanks.
The problem is, if you are new to something, you rely on the available documentation...

@JW914: I statet in my OP that the remote router is a FritzBox, and they just suppor ipsec, so my choices are rather limited.
And: using my preferred search engine is more or less what I spent the weekend doing. What came out of that is that everybody who described setting up a site-to-site ipsec VPN on Openwrt configured the firewall manually, i.e. by iptables commands in firewall.user. Nobody used the documented setup.

vgaetera · October 15, 2018, 2:21pm

Do you have administrative access to it?

georgh · October 15, 2018, 4:07pm

I have admin access to the FritzBox, but no physical access - it's in Germany, about 10.000 km away from my present location in Brazil. So, if anything goes wrong, I am stuck, and a bunch of people are without internet and telephone. Btw., the AVM dokumentation clearly states that it's built in VPN uses ipsec, and describes it's parameters. As mentioned in my OP, I have the VPN up and running, with StrongSwan on a linux server. The problem is not building an ipsec VPN to a Fritzbox, the problem is doing in from an Openwrt router

I need the router anyway, the f***g box provided by my ISP does not even have WLAN, but DHCP is on and spans the whole 10.1.1.0/24 net, no DNS... good enough for the average person with a lapotop, a bunch of smartphones and a chromecast to watch Netflix, but not for a techie guy. And connectivity should be on the router, not a random machine on the net that may be down for whatever reason.

So, I am stuck with setting up StrongSwan on Openwrt.

JW0914 · October 15, 2018, 4:41pm

You wouldn't remove the IPsec configuration until after thoroughly testing the OpenVPN connection, of which would include a reboot to ensure the connection comes back up without issue.

Also, don't you have SSH configured (as let's say you lost access due to do the IPsec tunnel being down)?

slh · October 15, 2018, 5:06pm

The remote router is a AVM Fritz!Box, which only supports IPsec/ IKEv1, not OpenVPN, not wireguard, no IKEv2 and no deeper configuration possibilities for the IKEv1 setup. It doesn't make sense to discuss alternatives (better or not) which aren't supported by the remote end anyways.

@georgh given that you appear to have a working strongswan ipsec.conf, you should be able to use that on OpenWrt as well, provided you install the packages needed to support that functionality (for size reasons, OpenWrt splits it into many tiny packages), if your local router has the space, installing strongswan-full might get you further.

georgh · October 15, 2018, 7:30pm

slh: Thanks. the nFritz!Box is a consumer market product (high end, IMHO), and the VPN scenarios covered by the manufacturer are site2site, using 2 Fritz!Boxes, or a road warror, for whom AVM provides a windows (only) client. besides that, on their web site they publish the IKE parameters the use.

And, yes, I have a working ipsec.conf, of, better, a pair of isec.conf and Fritz!Box setup file, that work together. It took me a day fiddling with the IKE settings on the StrongSwan side, but I got it to work.

What is different now is that there is one more NAT (the Openwrt router), so I will have to change the remote (FritzBox) / local (OpenWrt) network address. That should do it, as long as the Fritz!Box is reached from the local network (it is), and the rooter sends keep - alive packets frequently enough to keep the ports of my ISP's CGNAT - junk open.

The point I hung is the Openwrt's firewall configuration. The documentation describes an "elegant" way to do everything through the uci / Luci interface, but a crucial script (firewall.sh or fireqwall.ipsec) for that to work is missing. What I was hoping to get out of the forum was a comment from one of the developers, like either "Oops... there went something wrong in 18.06.1..." or "That's called xyz.sh now" or "forget it, that never really worked, do it the old fashioned way."

zlob-bik · January 25, 2019, 5:45pm

Any new from OpenWrt Strongswan as vpn Client to another L2TP/IPSEC Server?
I need this solution too.

dchard · May 7, 2022, 10:01am

I am having exactly the same issue: need to connect to a server that only support IPsec IKEv1. I have an ipsec.conf that runs perfectly fine in a VM behind the OWRT router (bridged to the LAN subnet of the router), but when I try to load this working ipsec.conf to openwrt,it negotiates phase1 successfully, but that is the end of it:

root@XAX6:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.5, Linux 5.15.34, aarch64):
  uptime: 2 seconds, since May 07 11:28:13 2022
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 1
  loaded plugins: charon md4 socket-dynamic stroke test-vectors pkcs11 aes des blowfish rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pgp dnskey sshkey pem openssl gcrypt af-alg fips-prf gmp xcbc hmac attr kernel-netlink resolve socket-default connmark farp vici updown xauth-generic dhcp
Listening IP addresses:
  192.168.2.254
  87.97.X.X
Connections:
VPN_NOC-VPN_NOC_c:  %any...144.178.X.X  IKEv1 Aggressive, dpddelay=10s
VPN_NOC-VPN_NOC_c:   local:  [xxxxx.yyyyyy.zzzz] uses pre-shared key authentication
VPN_NOC-VPN_NOC_c:   remote: [144.178.X.X] uses pre-shared key authentication
VPN_NOC-VPN_NOC_c:   child:  192.168.2.0/24 === 10.5.5.0/24 TUNNEL, dpdaction=restart
Security Associations (0 up, 1 connecting):
VPN_NOC-VPN_NOC_c[1]: CONNECTING, 87.97.X.X[xxxxx.yyyyyy.zzzz]...144.178.X.X[%any]
VPN_NOC-VPN_NOC_c[1]: IKEv1 SPIs: f3c551cf5c357e07_i* 0000000000000000_r
VPN_NOC-VPN_NOC_c[1]: Tasks queued: QUICK_MODE
VPN_NOC-VPN_NOC_c[1]: Tasks active: ISAKMP_VENDOR ISAKMP_CERT_PRE AGGRESSIVE_MODE ISAKMP_CERT_POST ISAKMP_NATD

Openwrt is the initiator, no firewall rules are added or modified by me. Using strongswan-default package. proposals are checked and they match (looking at Wireshark both OWRT and the remote server sends the same proposals).

It would be nice if someone can help, as I ran out of ideas...

slh · May 7, 2022, 11:41am

I'm a bit rusty in regards to strongswan, as I moved over to wireguard a bit over 4 years ago...

--
cgNAT forced me over, as the wireguard android app works fine over IPv6, while the strongswan android app doesn't support IPv6 - and thanks to cgNAT, I have no IPv4 address allowing incoming connections.

dchard · May 7, 2022, 11:41am

I am also using Wireguard, but in this case I have no choice...

dchard · May 7, 2022, 1:07pm

@slh Hm... I am managed to set up the tunnel finally, but packets are routed outside of the IPsec tunnel as of yet...

Connections:
VPN_NOC-VPN_NOC_c:  %any...144.178.x.x  IKEv1 Aggressive, dpddelay=10s
VPN_NOC-VPN_NOC_c:   local:  [xxxx.yyyyyy.zzzz] uses pre-shared key authentication
VPN_NOC-VPN_NOC_c:   remote: [144.178.x.x] uses pre-shared key authentication
VPN_NOC-VPN_NOC_c:   child:  192.168.2.0/24 === 10.5.5.0/24 TUNNEL, dpdaction=start
Security Associations (1 up, 0 connecting):
VPN_NOC-VPN_NOC_c[1]: ESTABLISHED 35 minutes ago, 84.236.x.x[xxxx.yyyyyy.zzzz]...144.178.x.x[144.178.x.x]
VPN_NOC-VPN_NOC_c[1]: IKEv1 SPIs: cc404d97959217f9_i* b89431274e1684cb_r, pre-shared key reauthentication in 2 hours
VPN_NOC-VPN_NOC_c[1]: IKE proposal: AES_CBC_192/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072
VPN_NOC-VPN_NOC_c{1}:  REKEYED, TUNNEL, reqid 1, expires in 24 minutes
VPN_NOC-VPN_NOC_c{1}:   192.168.2.0/24 === 10.5.5.0/24
VPN_NOC-VPN_NOC_c{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c2e80c79_i f7792e8d_o
VPN_NOC-VPN_NOC_c{2}:  AES_CBC_192/HMAC_SHA2_256_128/MODP_3072, 0 bytes_i, 0 bytes_o, rekeying in 8 minutes
VPN_NOC-VPN_NOC_c{2}:   192.168.2.0/24 === 10.5.5.0/24

The solution to my problem was to completely remove all strongswan packages, then select "strongswan-isakmp" as main package (enables the required dependencies), plus I needed to select "strongswan-mod-sha2" as my server side requires that. After the above, the tunnel started to come up. Not 100% sure, but I would say that the main issue was that swanctl and strongswan-ipsec was enabled in the same time...

Now I only need to resolve this routing issue. The left and right subnets (192.168.2.0/24 === 10.5.5.0/24) are correct, so my packets are getting NAT-ed before they can reach the tunnel.

sagar_jain · July 22, 2022, 11:35am

Use this rule.

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

It might solve your problem.