i updated an test pfsense to 2.6 dev version and the problem is solved.

I can confirm that saving the WAN interface (without changes) indeed worked as a workaround. All is working now. Thank you!

I have found the problem; https://redmine.pfsense.org/issues/11524 It is related to the combination of AES-NI and P2 SHA256. Temporary workaround: disable AES-NI I hope this will be fixed soon!

I was just searching this topic, not for the same use case but to centrally manage a lot of pfSense appliances, I think being able to set them up as IPsec clients with a virtual IP would be useful. At this time I have to create a separate tunnel for each managed pfSense, instead of dynamically provisioning virtual IPs via Radius. I'm pretty sure the answer is no, and the strongswan virtual IP option cannot be used with pfSense as a client.

The difference between those screenshots is the IKE version (IKEv1 vs Auto), the missing field is only valid for IKEv2 (and Auto can use IKEv2). It's not likely to be related to any problem you are seeing.

@eric-scace Last point: Everything works fine if there is only one Phase 2 definition for the full subnet at each site — except, of course, all traffic gets encrypted. Another way of looking at this problem: How does one take a tunnel between two sites that encrypts traffic (10.32.0.0/12 ︎ 10.160.0.0/12)... and divert traffic between a specific subset pair of address ranges (source & destination... in this example 10.40.0.0/13 ︎ 10.168.0.0/13) to be sent (potentially through a different tunnel) in the clear?

@msswift Thank you that fixed it for me too!

It's not a fatal error, just annoying log spam. No way to suppress it currently.

Unlikely. It would work as long as they were both using dyndns to give the other something to open a state to and the provider is not using source port randomisation. They probably are though. Steve

@c-zaborowski 7 Years and four major versions later, this helped us soooo much. Thank you Sir

@jimp Hi there, I updated to 2.5 and found that my site-to-site IPSEC VPN connections were broken. I found this thread and installed the aforementioned patches which fixed the VPN (including the Status->ipsec page) but the ipsec status widget still seems to be broken, i.e., they show connected on the Status->ipsec page but show as down on the Widget->Tunnels tab. Thanks

I don't know why the VPN worked before the upgrade (sarcasm). The thing is, I added the rule in the target subnet (VPN assigns 162.168.10.0/24 for remote clients targeting in 192.168.1.0/24) to allow communication on ports 50, 51, 4500 and 1701 on 192.168 .1.0 / 24. This has definitely solved the problem.