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...

@Piter-0 Hello! I have the same problem! If WAN 1 fails, I still can't connect to WAN 2! If I deactivate ipsec for a short time and then activate it again, it works over WAN 2 until next time!

@frog Not that I know. But if your subnets are successive you can state a larger subnet, which includes all or multiple at least. E.g. your subnets are 10.66.20.0/24 10.66.21.0/24 ... 10.66.29.0/24 10.66.30.0/24 So set you local network to 10.66.25.0/20, which includes 10.66.16.0 - 10.66.31.255. However, you will also have to configure the remote site accordingly.

Ok, I believe I've found the root cause and it was a misconfiguration. I have "Manual Outbound NAT" configured. This is to use a 4 address pool instead of the firewall's WAN address for NAT. So even though there was an wildcard "Auto Created Rule" for TCP port 500 (ISAKMP) using the WAN address, there wasn't a rule for the ESP protocol. I added a wildcard rule for ESP that used the WAN address last night, and haven't had any issues since. In retrospect, this makes sense, since each time I lost connection, the source address was one of the addresses in the pool. What doesn't make sense to me is that it ever used the WAN IP address. Like so many things, it would have been a lot easier to diagnose than a connection that always failed than one that sometimes worked. I think an argument could be made that if pfsense is going to add an Auto Created Outbound NAT rule for ISAKMP, it should probably create an Auto Created rule for ESP at the same time.

@keyser That worked perfectly! Thank you guys!