Route based IPSec, traffic is not processed

[NicoLK]

Hello folks,

currently I'm trying to setup an IPSec tunnel from an OPNsense HA cluster to an Sophos XGS. I've tried using a normal policy based tunnel but it didn't work with HA. Even though I used a CARP IP (tried both WAN and LAN CARP IPs) the secondary firewall always tried to establish the tunnel as well. This caused the tunnel to crash because the OPNsense is behind a NAT Router. Also the primary firewall didn't disable the vpn connection when it was set to CARP maintenance.

Since fast fail over would be nice I tried a route based approach. However there is some stuff going on with the traffic that I can't explain.
Traffic from the Sophos reaches the OPNsense. I can see it in the firewall logs and in packet captures on wan, enc0 and on the vti. But the traffic is not processed. For example pings are not being answered or forwarded.
Doing the same thing from the OPNsense (f.e. ping the other firewall) however can be captured on the vti interface but there is no traffic on enc0 or wan.

So far I tried many things but I could not affect this behavior. I think it might be an issue that Sophos uses strongswan with an xfrm interface and OPNsense uses strongswan with vti. However I could not find any mention of these two not being compatible with each other.

I use OPNsese 25.7.4 but it also happened on 25.7.3.
The tunnel is set up with 0.0.0.0/0 for phase 2 and currently static routes are used. For testing purposes I disabled the tunnel on the secondary OPNsense firewall.

If you have any idea, let me know.
Thanks

[Monviech (Cedrik)]

If a tunnel gets established or not is controlled via the "Start" Policy of a child.

If you set it to TRAP it will only start if there is matching traffic. This means it will not be initiated on the backup firewall since there shouldnt be any traffic that matches the TRAP policy there until a failover happens.

[NicoLK]

I've already tried that and it works for the secondary. However if put the primary firewall into CARP maintenance, it does not disconnect the tunnel.

[Monviech (Cedrik)]

Can you let the other side initiate?

You can set your children on NONE.

Even if a VPN tunnel remains UP, it should not matter since DPD could handle this.


You can also try UDP Encapsulation on 4500, maybe that ensures sockets are unique, otherwise it might communicate 4500-4500, source NATing both firewalls to the same outbound port if static port is enabled.

[NicoLK]

Unfortunately I can't. On the OPNsense side there is a regular internet connection. No static IP. So I'm already using UDP 4500 with DPD. Because the OPNsense firewalls are behind a NAT router, the router does not redirect packets correctly because it gets several packages from the same IP and MAC but the port changes on which the MAC of the CARP relies.
This is why I tried using an internal CARP address and NAT outgoing packages from that IP to the local WAN IP. However the Sophos firewall then gets duplicate packages and at some point closes the tunnel with an error (takes about 5 minutes). This causes the primary firewall to close the tunnel until it's re-initiated manually.

I tried using traps instead, which worked better. However a planned CARP maintenance (f.e. an update) did not switch over the tunnel. The primary firewall in maintenance mode had the tunnel still active and the secondary, now receiving traffic, tried to open the tunnel. This again caused the behavior above.

So my next approach was to use a route based tunnel and use dynamic routing in the final configuration. But for initial testing purposes I used static routing and disabled IPSEC on the secondary firewall. For testing purposes I also created an any any rule and set it to logging, so I could see traffic that is transmitted via enc0 (IPSEC firewall interface).
But after some days of testing I saw the behavior which I mentioned in my first post and didn't know what to do or how to search for that.

I'm not sure what you mean with "setting children to none". If I don't have a phase two, then I guess no packets could traverse the tunnel. To my knowledge a phase to is always needed?

[Monviech (Cedrik)]

I meant setting the START ACTION of all CHILD(ren) to NONE.

This would make the OPNsense the responder only. The other side would have to initiate then.

The NATing Router in front of the OPNsense could then Port Forward (destination NAT) to the CARP IP address.

The initiator would then handle initiating a new IKE for Phase 1 when DPD would kill the session after a failover.

But with your specific issues, when you do a carp maintainance, you could also simply stop the strongswan service manually on the primary firewall as additional step.

[NicoLK]

I guess that would work. Not my preferred solution because it would cause quite a bit of dropped packets and connection losses for the remote side but technically it should work.
If there are any ideas for the route based tunnel, let me know.