@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" :)

@tinfoilmatt I could just as well use OpenVPN for S2S as the workaround. But i Prefer Wireguard due to it’s simplicity - I find it’s just as fast as OpenVPN with hardware acc. There is nothing wrong with either of those options - it’s just not enough in many cases… I’m not always in control of the other ends hardware, and IPsec then becomes the golden standard, and thus required. Also, I much prefer to have only one VPN engine/setup running on pfSense - My “KISS OCD” does not like having multiple different VPN suites/rules and setups running when just IPSec should be enough. PS: The pfSense mobile warrior IPsec setup is not replaceable :-) I, and my customers, absolutely LOVE the pfSense Mobile VPN with it’s simple setup, and grouping of firewall rules due to multiple IP pools. Not having to deploy and maintain VPN clients, but just use the ones built into OS’s is an absolute WIN-WIN when coupled with 2FA from the MS Entra plugin to Microsofts NPS radius server.

I have made some progress. I have modified the file /src/etc/inc/ipsec.inc at lines 2365 and 2365 to remove the additional selectors, and now my proposal correctly matches the one on the other side and it works flawlessly.

@itBJA In the p2 you can only masquerade your network. However, for communication also the remote site has to masquerade their networks. Otherwise you were not able to access anything there or lose access to the local network. This could look like that: At local network state 172.16.0.0/16. At NAT/BINAT select network and enter e.g. 10.16.0.0/16 At remote enter their masquerading networks. E.g. 10.116.3.0/24 for 172.16.3.0/24. The remote site has to use 10.16.0.0/16 as "remote network" and nat 172.16.3.0/24 to 10.116.3.0/24. Then you have a 1:1 NAT. This means if 172.16.3.26 on your site connects to 172.16.3.26 on the remote site, it needs you use 10.116.3.26 as destaintion.

@keyser said in Change local source ports of IPsec tunnels: I think you are looking for the “custom ports” settings on VPN -> IPSEC - ADVANCED tab But this sets the port globally for IPSec, but I don't see a way to state a specific port for a certain connection, as the OP requested.