@ofloo Thanks. couple of small points: your shebang is for bash -- did you install bash on your firewall? (pfSense does not come with bash) you could use pkill -F /var/run/charon.pid which is more concise and doesn't need the cat wouldn't you need to tail -n10 etc to be sure you weren't just reading the same "trap not found" message over and over in a loop? you don't need the extra if-test and pipe to wc, you can test the result code from grep directly maybe something like this would work? (I have not tested this) #!/bin/sh if tail -n10 /var/log/ipsec.log | /usr/bin/grep -q "trap not found, unable to acquire reqid"; then pkill -9 -F cat /var/run/charon.pid echo "Executed Charon kill script, IPsec seems locked up" fi exit 0

Just did another test: While beeing in this stituation: failback on the lan-carp-ip happened to node1 node2 has the IPSec still established I can continue using the tunnel, if I manually change my gateway from the lan-carp-ip to the second nodes ip address. So, overall the master node does not reestablish a connection, because the connection is healty - but it is just no longer accessible for lan-clients. However, the roles themself claimed that fallBACK also has happened for the wan-carp-ip, so it might be an issue on the wan site, where packages of the tunnel communication are still send to the backup-node, even if it does no longe own the wan-carp-ip. This leads to the clusters assumption that the tunnel is healty and no reconnect is required. But beyond that observation, I could only start to guess, because I'm not familiar to how the whole carp thing works. If it uses MAC-spoofing, there shouldn't be any missrouted packages. If both of the nodes use an own mac-address with the wan-carp-ip it might be the routers mac-address-table / cache that keeps sending packages to the MAC of the backup-role, keeping that tunnel alive and "healthy", which finally surpresses the reconnect of the master role, that would be the one that is accessible by the lan-carp-ip.

Figured it out thx to a post in the UTM-Forums that is ... ehm... 5 years old :) The Sophos has an Issue with AES 256 along with SHA 256. Dropping to SHA-1 and it starts to work out of a sudden. (Not to mention it does not support IKEv2) We'll, we are looking for a new Appliance on the HQ-Side anyway, so i'm now going to look deeper into pfSense https://community.sophos.com/sophos-xg-firewall/f/discussions/89213/ipsec-vpn-with-utm-not-passing-traffic?ReplyFilter=Answers&ReplySortBy=Answers&ReplySortOrder=Descending

It appears Bug #13074 ( https://redmine.pfsense.org/issues/13074 ) has been created for this.

@pelikanruban This. If you had a pcap going at the same time there's no evidence the pings ever came through. What is the "other" platform? Have they shared their config file with you so you can verify your settings match theirs?

@phlmike you can probably add each PC with a /32, which might 'read' more elegantly than the two /29. I'm also wondering if the Alias you have already created could be utilised in the phase 2 declaration for this purpose. Never tried it.

You can disregard this post This was an issue where the WAN ip address had a 223 in the WAN ip address and I put in a 233. My brain missed it again until a coworker took notice

@timboau-0 Thank you. I tried 2.5.2, and the same result just showed connecting on the same two connections that I was initially having issues with. I will mess with this more after hours and try rebuilding the P1 and P2 from scratch to see if that helps unless someone has any other suggestions.

Hi, I have the same problem. LDAP works. An LDAP user can logging in to the web interface. Diagnostics / Authentication also works. When a local user (EAP Keys) logging in to Ipsec VPN, everything works. I have the same errors when logging in to an LDAP user. 16 [IKE] <con-mobile | 60> no EAP key found for hosts '000.000.000.000' - 'ldap_user' 16 [IKE] <con-mobile | 60> EAP-MS-CHAPv2 verification failed, retry (2) Thank you

@nocling I tried Ipsec using IPV6 and had pretty weird errors (This was with a starlink service so it does drop more than you would like) - essentially it wasn't stable as an ipsec tunnel (this was using 2.5) - switched over to WireGuard and its been working really well - just doesnt seem to be 100% support from netgate yet so reluctant to replace all ipsec with WireGuard.

I've been informed, "If you have XMLRPC sync the VIPs that would work as the IDs would match on both. VIPs have to be tracked by ID, not IP address. Thus you have an unsupported configuration if you are managing the VIPs by hand but expecting other areas of the configuration to sync via XMLRPC." It's been years since it was set up, but if I go back I do see "Virtual IPs" is unchecked in the HA sync settings. I had to dig into deep areas of my brain but looking at the config, I think it's because we have one IP alias that isn't on the WAN or LAN CARP ranges and that needed to be different on the two, so the VIPs couldn't be synced. I didn't play with that though. What I did was edit the <uniqid>xxxx</uniqid>values in the backup router to match those on the primary router, and restore. That seems to have resolved this error message.

In version 2.5.2 if you let apply the changes

@pfsenseuser1 What does the IPSEC dashboard widget display? Also check in: http://{IPADDRESS}/status_logs.php?logfile=ipsec in setting you can reverse the order so recent is at the top.

@yguerchet The topic is old, but i solved it. By enabling "split connection"