Forgot to mention Site A uses Cox Cable and Site B uses Comcast.

On the Fortinet router make sure you have the necessary firewall policies and the source/destinations for each policy are set up correctly. Please also reference my post on this thread: https://forum.netgate.com/post/1169622 The correct way to set up hub/spoke topology in multi-platform setting would be use 0.0.0.0/0 routing via IPSEC interfraces. However, this was broken in 24.03 and I'm afraid it will be broken in 2.8.0 CE as well, despite this functionality being there for years and working flawlessly.

@viragomann They are all set to any already. that was my exact thinking get them up and then tighten them down once they were up.

I thought I'd do some further testing with earlier versions of CE, specifically 2.6.0. I'm happy to report that 0.0.0.0/0 works identically to 2.7.2. That version was released in the beginning of 2022..

I found the missing link! On the NPS server, I had to set the following registry entry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureMf Create the following String/Value pair: Name: OVERRIDE_NUMBER_MATCHING_WITH_OTP Value = FALSE Then I had to restart the Network Policy Service and BINGO! I got the approve sign-in notification on my phone when I tested the RADIUS logon. Because I had number matching turned on in my tenant, the extension was falling back to TOTP which obviously won't work with MSCHAPv2. See this link: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match#nps-extension

Have you read https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/routed-vti.html? That doc suggests configuring a transit network (which could be a /30), and that the two endpoints of the transit network would be configured as ADDRESS rather than NETWORK in the P2. You don't mention which version you're running, but if you are on 24.03, note this thread https://forum.netgate.com/topic/188214/vti-gateways-not-adding-static-routes-in-24-03/. There is a patch to address the issue of the necessary static routes not being added. --Larry

@nzlv Your Virtual Net Address pool is not configured correctly. The 24 should be in the drop down and not in the IP range. I have to wonder if this is somehow messing things up routing wise. [image: 1717727361503-05597bd7-477f-4424-8363-271f83984494-image.png] Also, I think you may want to check the "Provide a list of accessible networks to clients" on the Mobile Clients tab. [image: 1717727838107-b484b850-6638-47ec-924e-c5c866fcbdc9-image.png]

@Anders-Mogensen-0 After many hours of troubleshooting, I found a "rough" unit on the network with the same IP! But it is still strange, that disabling the WAN1 port, would make everything work as expected...

Thank you @NOCling and @keyser for your insight. I went back and reviewed step by step 2 guides from the Netgate documentation: For Remote VPN connections with Certificate, I followed this guide: https://docs.netgate.com/pfsense/en/latest/recipes/ipsec-mobile-ikev2-eap-tls.html And for Site to Site VPN connections with Certificate, I followed this other guide: https://docs.netgate.com/pfsense/en/latest/recipes/ipsec-s2s-tls.html My issue was I got creative and changed some settings the first time. After knowing @keyser and @NOCling were able to make it work, I followed those 2 the guides, and everything worked fine! Thank you both!

I was wrong 10.10.6.0/23 is the overlapping network. That should NAT to 172.28.120.0/24, 172.16.209.0/24, 172.28.118.0/24, 172.28.117.0/24 with address 172.27.12.160/27 from my side

@keyser Thanks for the recommendation. I can't believe I overlooked this much simpler solution. I zapped the NAT port forward rules and just created a new hostname for the VPN which resolves to the public IP on the LAN. Also, thanks for taking the time to provide details on IPSec and ESP.

@viragomann @viragomann said in Site to site vpn would like to route all traffice from one device and force acrosss vpn: @roveer said in Site to site vpn would like to route all traffice from one device and force acrosss vpn: I made sure all my settings were "network" 192.168.0.20 and /32. Is it possible that my firewall at Site A (running 2.4.4.4) doesn't support such addressing in P2's? Eventually I'll upgrade this FW to latest. Updating pfSense is a good idea anyway. In newer versions you can select "address" in the p2 for a single address. I think, that's not possible in 2.4.4, so "network" with a /32 mask would be the proper setting. Also some devices do not accept overlapping IPSec p2 networks. But current pfSense versions do. Will definetly update. I've got another exact match hardware box so I can easily implement newer pfsense at Site A. I noticed many of the differences between versions. Some as simple as moving the description box to a different location, others that had different pulldown options. I was starting to think that the older version wasn't limiting the forwarding of the single ip address. When I fired it up I immediatly started seeing addition VPN traffic in the graph. Hopefully latest same/same versioning will allow this to work. I'll report back as I like to close the loop on these little projects in hope that it helps someone in the future. Roveer

@pkuzniasz Did you state a gateway in the LAN interface settings by any chance? If so and there are no good reasons for this, just remove it.