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.

@keyser said in Routing Firewall A over IPSec to Firewall B: There is a workaround that I’m using to allow my two firewalls to talk to each other using their LAN Static Ip address. Agree, your workaround enables the IPSec endpoints to talk to each other. But the primary issue of this thread is to forward public requests over the VPN to a device at the remote site. And this cannot be done with policy-based IPSec, as long as you do not nat the packets to the LAN address on the remote, but this is mostly not wanted.

@johnpoz Thanks, that's all I needed to know

@oscar-pulgarin The question is, what the remote site logs regarding this connection, however.

nevermind, the link took care of it.. https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat.html#firewall-state-policy jim