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.

@KevCar87 You might be able to make your preference, policy based or route based (VTI), work... pfSense documentation on policy based (tunnel mode) Otherwise, per that first warning box ("NAT is not currently compatible with route-based VTI IPsec tunnels without configuring an IPsec Filter Mode which is incompatible with tunnel-based IPsec."See Advanced IPsec Settings for details.")... pfSense documentation on VTI ...route based (VTI) will require additional configuration beyond what the WatchGuard documentation appears to cover (more specifically here under "IPsec VTI Filtering").

@Averlon Indeed. There are valid use cases for both options. Thanks for the feedback

@HyperactiveSloth Hmm, my VTI tunnels status shows 0.0.0.0/0 as the network in both ends in order for me to assign what traffic goes down the tunnel (by assigning routes to the VTI Gateway created when the IPsec interface sis assigned). Your IPsec status looks like a tunnelmode Phase 2, where the local/remote subnets are assigned in the Phase 2 settings. Strange…. If it was tunnelmode I’m quite sure your issue is the “missing” split connections setting…. Guess I’m out of ideas :-(

@keyser I could also change the connection between the affected sites to Wireguard. The downside is I end up with two VPN Technologies for Site-to-Site connection too, cause not all my devices are Wireguard capable. I also have to evaluate how Wireguard interact with dynamic routing running FRR and especially BGP. It might be worth looking more closely into this and switch to Wireguard where possible. The lack of IP fragmentation support with VTI IPsec is also annoying. I suspect a sort of regression causing this issue. If we're lucky it's due to changes of default configuration and this may get fixed on the fly. But so far I haven't spotted any, when comparing IPsec related settings between 2.7.2 and 2.8.1.

@viragomann OK, I’ve created it this way and I’m going to monitor the status to see what happens and how the tunnel behaves from this point on. Thanks a lot!

Ill give it a try- From post.txt above.. Hi, PfSense Plataform: CE 2.8.0 and 2.8.1 The generated list by the Status/IPsec/Leases page appears to be including clients with null IP addresses in the calculation of online clients (command line output below), when only those with real assigned IP addresses are listed on the page. This leads to a very large discrepancy between the clients considered online and all established IKE SAs, output of the command swanctl --list-sas | grep ESTABLISHED | wc -l If the null IPs listed as online are excluded from the listing, the listing will be consistent with the list shown on the page, more realistic and practically identical to that of the established IKE Security Associations (SAs). swanctl --list-pools --leases | more (null) online 'gustav' (null) online 'gustav' 192.168.100.226 online 'johnk' Comparison: Status/IPsec/Leases page output: 200 leases on line swanctl --list-pools --leases | grep online | wc -l 200 swanctl --list-pools --leases | grep online | grep -v null | wc -l 119 swanctl --list-sas | grep ESTABLISHED | wc -l 121 Thanks, Geovane

@krismortensen An 1100 might be a bit under powered for an encrypted VPN, but it should be functional. https://info.netgate.com/hubfs/website-assets/netgate-hardware-comparison-doc.pdf Wherever you host Tailscale, it should be on an always on device. I enable pfSense Tailscale instance as an exit node, which I can use to tunnel all my traffic through my home IP address when connected to untrusted networks.