@thespirit I don't think it is really a bug. If it was changed so the auto-added rules were not overridden by a block all rule then that would be equally confusing as block all wouldn't mean block all. The way the code which generates the rules works it is pretty clear that user added rules should always take priority it probably just needs to be mentioned in the documentation somewhere.

@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 :-(

The widget shows that all three tunnels are up. However the Sophos side still says that there is no connection on the third tunnel. Also cannot ping across. [image: 1762831782639-snag_233c72.png]

@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.

Ok that's good information. 20s like that sounds like a redirect timing out. And where that would apply in 2.8 might be change in default for firewall state policy from floating to interface-bound: https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat.html#config-advanced-firewall-state-policy Specifically this applies to VTI tunnels when the IPSec filter mode is still set to the combined ipsec tab: https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat.html#ipsec-vti-filtering I would bet that's what you're hitting unless you've tested it already.

@viragomann It solved the problem. Thank you.

@keyser Ah. Silly me I was looking for "class" :)