The quick answer is you'll need to set the IPsec Filter Mode to VTI to allow those interfaces to use reply-to so the response traffic will use the correct interface. Set it on both sides. That will break any tunnel mode IPsec tunnels you may have, but if you don't have any, then it's only a positive change. The more complicated answer is that you should really run a dynamic routing protocol like BGP between those routers using the FRR package so the routing changes in a more reliable and predictable manner and isn't relying on filter trickery to avoid asymmetric routing.

Circling back to this, I've been researching whether this is possible with pfSense's current strongSwan implementation or whether a code change would be required. Unfortunately, this isn't currently possible. Here's why: The Core Issue: socket-default vs socket-dynamic strongSwan has two socket plugins that handle IKE packet transmission: socket-default (what pfSense uses): Opens two fixed UDP ports (500 and 4500) at daemon startup. These ports are shared globally by all connections. The local_port setting in swanctl.conf is ignored because the socket layer doesn't support per-connection ports. socket-dynamic: Opens sockets dynamically on a per-connection basis, allowing each tunnel to specify its own local_port. However, this plugin is marked as experimental and has significant limitations. Why socket-dynamic Isn't a Simple Solution Cannot use port 500 - The plugin enables UDP encapsulation on all sockets, so standard IKE packets without the non-ESP marker are incorrectly processed as ESP by the kernel. You must use NAT-T ports (4500+) exclusively. No coexistence - You cannot load both socket-default and socket-dynamic simultaneously. The socket layer operates at the daemon level, not per-connection. Both plugins would attempt to bind the same ports, and only one would actually receive packets. Requires remote NAT-T port - Connections must set remote_port = 4500 (or another NAT-T port), limiting interoperability. Current Workarounds Multiple WAN IPs: Bind each tunnel to a different source IP address via the Phase 1 Interface setting Different remote ports: If your VPN vendor can accept connections on different remote ports, pfSense does support per-connection remote_port settings References strongSwan FAQ on custom ports: https://docs.strongswan.org/docs/latest/support/faq.html strongSwan socket-dynamic discussion: https://github.com/strongswan/strongswan/discussions/927 swanctl.conf local_port documentation: https://docs.strongswan.org/docs/5.9/swanctl/swanctlConf.html Hope this helps anyone else investigating this limitation.

Thank you, @luckman212. I played around with the settings you pointed out and got it to work. I know this was an old thread, but now other people with the same issue can find guidance. Thanks again!

@ivica.glavocic Check out this article from the documentation, Assigning OpenVPN Interfaces. That's one way to get OVPN traffic onto an interface that can then be NAT'ed to/from. (This confusingly-named subsection, Allowing traffic over OpenVPN Tunnels, then becomes relevant, too.)

Hello, same here, Pfsense 2.7.2, have lot of IPSEC tunnels with multiple P2 but just one IPSEC with 2 P2's just one is not showing in status up and doesn't works. Any suggestion?

@jlw52761 my thinking as well

@bh2026 not used IPSec myself but have you read through Netgate documentation: IPsec Site-to-Site VPN Example, Firewall Rules. Are there firewall rules in place for the VPN clients to access?

@tinfoilmatt Both the connections use the same reqid. And that is the problem because the reqid is used for creating SAD/SPD entries. The result is that there are two SPD entries pointing to the same SAD entry which makes the formerly established connection not working because there are wrong encryption values used.

@jbates58 The right side connects to the left side? The listener/server is site B here: https://docs.netgate.com/pfsense/en/latest/recipes/ipsec-s2s-psk.html#site-b and has a few differences like Child SA Start Action and LifeTime and Child SA Close Action. I can see one end of a client's tunnel from here, and Dead Peer Detection is off for it; I want to say we did that on both ends but am not sure offhand. On that router we have "Peer identifier" set to the FQDN of the other end.

@femtosize Ohh yeah i see what you mean. Yes I do agree, an info on the documentation would definitely help here! In this case, this post can be considered as done.

@conbonbur Here's an option/idea from the docs using OpenVPN instead of IPsec: OpenVPN Site-to-Site Configuration Example with SSL/TLS 'Hub and spoke' is the topology you're after—where Site A would be your so-called 'hub', and Sites B and C the so-called 'spokes'. Pretty sure a hub-and-spoke topology could be accomplished with IPsec by implementing a particular NAT configuration and/or static routing. But either way the short answer is: yes, it's possible.