strongswan: use own updown script

[feckert]

Maintainer: @pprindeville, @Thermi Compile tested: x86_64, APU3, OpenWrt 21.02 Run tested: x86_64, APU3, OpenWrt 21.02, start a connection

Description:

Stongswan does provide an own updown script in its source package. This should serve as a basis and can be extended by the user. With openwrt it is usual that a new updown script is installed with a new version.

To fit better into the hotplug script handling of openwrt and because of using iptables commands directly this commits moves the current source updown script its own ipsec hotplug script.

Additionally a nftables updown package is added to fix strongswan with fw4 (nftables). From my point of view we should also update the ipsec init script to use the new _updown-openwrt as default and not the _updown script from the strongswan source

The following subtasks must be merged before hand:

• [x] https://github.com/openwrt/openwrt/pull/9909 merged https://github.com/openwrt/openwrt/commit/9379bc2fcf905568ef329a121c8c8a11fc98b02c
• [x] fw4 include feature

[feckert]

@pprindeville I have just set up an environment with which I am testing the strongswan with the new fw4 (nft) of openwrt.

Currently it is not possible in my setup to ping the remote site from the router with the current *tables-nft updown script! Something is wrong here! If I stop the firewall with /etc/init.d/firewall then the tunnel works out of the box. Unfortunately, I am still at the beginning of my investigation. But the first thing from my point of view is to clean up the current _updown script and move it to the ipsec hotplug handling of openwrt. That way, we can more easily replace the iptables script with an nftables script later.

[jow-]

@feckert - support for fw4 auto-includes has been merged into master and openwrt-22.03 now. The final path is /usr/share/nftables.d/ - if you update it accordingly in your PR it should be ready to merge.

[feckert]

I am on vacation till monday. I do not have the possibility to update this PR. Could to this on thusday.

Best regards

Flo

Jo-Philipp Wich @.***> schrieb am Do., 25. Aug. 2022, 10:24:

@feckert https://github.com/feckert - support for fw4 auto-includes has been merged into master and openwrt-22.03 now. The final path is /usr/share/nftables.d/ - if you update it accordingly in your PR it should be ready to merge.

— Reply to this email directly, view it on GitHub https://github.com/openwrt/packages/pull/18559#issuecomment-1226941884, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEHBA53RXMABQAUZ2XPP5DV24UUVANCNFSM5WEWFZEQ . You are receiving this because you were mentioned.Message ID: @.***>

[feckert]

@pprindeville All dependencies have now been merge. If there are no objections from your side, then I would like to merge this and also backport it to owrt-22.03.

In my opinion, otherwise the strongswan for generated traffic from the router is broken, since the required firewall rules are not added for fw4 (nftables). This pullrequest fixes this and leaves the user the option of using nftables via fw4 or iptables for fw3.

[stintel]

Honestly I don't see why this is needed. Use xfrm interfaces and add them in a firewall zone. No custom firewall rules and updown scripts needed at all.

[feckert]

Honestly I don't see why this is needed. Use xfrm interfaces and add them in a firewall zone. No custom firewall rules and updown scripts needed at all.

@stintel You may be right to use in the feature xfrm interfaces, but I currently I have the following setup in the field that previously worked with fw3 (iptables) with strongswan-mod-updown. And now it no longer works with the fw4 (nftables) setup.

I also added this two new packages to install either strongswan-updown-iptables or strongswan-updown-nftables independently of the strongswan-mod-updown.

Because if I change in the feature to xfrm interfaces I only need strongswan-mod-updown for hotplug events /etc/hotplug.d/ipsec handling to trigger some actions on client up/down events (Enable LEDs on client connection for example) But Currently the package strongswan-mod-updown is also installing on this event the the iptabels rules which I do not need if I use xfrm interfaces. I am aware that I can also switch off the firewall handling via configuration firewall (left|rightfirewall = yes | no). But I have to change the configuration in the field, which is not trivial.

So I think we anyway have to move the related firewall stuffs for strongswan-mod-updown for iptables into its own package strongswan-updown-iptables to fix the explained issues. Therefore, we can also fix the handling for the fw4 (nftables) and therefore outsource the setting of nftables rules into a separate package strongswan-updown-nftables.

[stintel]

I won't be using it, so I don't care to review it. My suggestion would be to contribute this upstream, and then backport to OpenWrt.

[feckert]

Anyone else from the package maintainers @pprindeville @Thermi using this?

I won't be using it, so I don't care to review it.

Too bad but I can understand if you don't use it and are not interested in a review.

My suggestion would be to contribute this upstream, and then backport to OpenWrt.

I can try, but it takes a long time to get it into the openwrt. I would suggest to merge this and if it is not working we could revert this.

The fact is currently it doesn't work without xfrm interfaces because the new fw4 (nftables) is not supported by strongswan-mod-updown

[Thermi]

The updown script isn't getting any love upstream because it's considered deprecated because it's only badly suited for handling of any configuration because it breaks on the first reauthentication or rekeying of CHILD_SAs. I am working on an updownv2 plugin that enables proper handling of such scenarios.

[pprindeville]

The updown script isn't getting any love upstream because it's considered deprecated because it's only badly suited for handling of any configuration because it breaks on the first reauthentication or rekeying of CHILD_SAs. I am working on an updownv2 plugin that enables proper handling of such scenarios.

I'm inclined to wait until something happens upstream also...

[feckert]

@Thermi @pprindeville Ok never the less we should at least change the dependency of strongswan-mod-updown. Otherwise we will always install the iptables dependencies when installing strongswan-mod-updown. Even though I don't need it.

If strongswan does not support nft from upstream or openwrt downstream then we should at least install only strongswan-mod-updown without any dependencies. If some on needs the iptables stuff then the new packeges strongswan-updown-iptables must also gets installed (See my pullrequest). Because I am using updown for other things not only for the firewall handling. The updown script for the firewall is only called if the option left|right firewall is set in the strongswan configuration.

[pprindeville]

Anyone else from the package maintainers @pprindeville @Thermi using this?

I'm using xfrm interfaces because they integrate well into the firewall per-interface rules...