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

Nothing specific. Is it upgrading from 23.09.1? Running UFS?

Some of the early RCC-VE devices like that had very small eMMC storage (4GB) which can be an issue.

Fixed by inverting the roles, I suppose it was something with NAT-T, UDP port 500 unreachable.

Jim was so kind to update my redmine with the explanation and closed the ticket.

The gist of it is that it is intended behaviour because SPDs are not an actual routing Table.
But If you want proper separation between the overlapped example I made, you can enable “Split connections” on the P1 that contains multiple P2s. That ways they each become a distinctive P2 SPD in the kernel, and it only routes the specific P2 associations you have defined.

Nice to know there was a solution, and case closed. Thanks @Jimp

Seems to be cypher related, as MacOS client now seems to connect fine, while iOS (17.4.1) still can't.

These are the cyphers currently enabled:

Screenshot 2024-05-03 at 3.42.46 PM.png

Any idea what's missing for iOS? I can't seem to find any docs on what it requires.

@planedrop Hmm, I think I have stumbled upon the same issue in a different usecase. In my case it actually prevents me from achieving what I intended, so this is a real problem for me.

https://forum.netgate.com/topic/187925/unexpected-phase-2-behaviour-combines-two-p2-to-one-established

It seems the Policy routing engine does not create a normal routing table but rather it does some sort of supernetting on local and remote nets - perhaps to attempt to only have one routeentry instead of a normal route table. But this is both highly problematic in terms of security and functionality.

@Chelex92 said in VPN is ok but some devices are not accesibles:

but cant see web portal of that Tp-link Access Points

One thing with AP, is sometimes they don't have gateways set - so you can not view them from other networks, since they don't know how to get back.. Do these AP have gateways set pointing back to pfsense IP?

If that is the case you can do a outbound nat, ie source nat so the device thinks your talking to it from the IP of pfsense on its network. This is just doing an outbound nat on the interface of the network this AP is attached to.