@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: [image: 1714765403208-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.

If you need to create connections across the tunnel in both directions you need a floating outbound rule with floating state binding set to allow the replies. It's shown in the doc there now. https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat.html#interface-bound-states So you might only add one floating rule and edit the existing IPSec rule. Two rules are needed if none existed.

@Konstanti My goal is to use this as my main gateway to the internet for a routable /24 (23.170.184.0) IP block and IPv6. I just have a simple test interface for now, to just get the link up (or so I thought). I use 8.8.8.8 for ping, as I don't have an EC2 to ping. Logs attached from AWS: aws-log.txt [image: 1714158746787-screenshot-2024-04-26-at-16.10.05.png]

Subnets wouldn't matter for that. The auth it's mentioning would be entirely in Phase 1, not Phase 2. The remote end is saying authentication failed so you will need to check the logs on the remote side (if possible) for any more detail about why it failed. In most cases it's down to something in Phase 1 either being mismatched or incorrect in some way (e.g. a config that could technically match multiple remote peers ends up matching both remotes)

@viragomann Thanx! You made me look at the "local networks" setting in the OpenVPN configuration and I had the subnet mask incorrect for the OPT4 interface /24 instead of /28 . So now connecting via OpenVPN I have access to IPSEC Interface machines with ip addresses of .97 to .110. I have two Phase2 objects on the IPSEC tunnel for two different subnet machines and they have been working fine being accessed from the 10.22.143.96/28 subnet. No changes there or additions. Data is flowing.

Gave up trying to troubleshoot this, took out the branch office pfsense, and connected the same VPN direct from the 4G/5G router. Worked instantly...