@nikhilsalunke Is it possibly linked to this?

https://forum.netgate.com/topic/89558/ipsec-pmtu/17?_=1634945881916

EAP / RADIUS can cause UDP packets that need to be fragmented and relies on PMTUD working.

@steveits Thank you very much, I just changed the setting. Let's see if that helps. Seems this issue pops up after some days or running.
I appreciate such fast response.

The 1 step was to push this config to clients, so the packet on VPN ipse is routed inside the Open VPN tunnel

alt text

Under local networks there are :

Lan,
the remote net identified in phase2 n.1
the remote net identified in phase2 n.2

You can't do that with policy-based tunnels.

You have two choices:

Keep the policy-based tunnels and setup Dynamic DNS and gateway groups on both sides so that if a WAN fails, the switches the hostname and single IPsec tunnel to the other WAN. This works, but takes a long time to switch since it relies on DNS (several minutes, most likely) Ditch the policy-based tunnels and use VTI. Configure two tunnels (1.1.1.1<->3.3.3.3, 2.2.2.2<->4.4.4.4) and use FRR with either OSPF or BGP to handle the routing. When setup properly, dynamic routing protocols are smart enough to detect when a path is down and use the other alternate path in a timely manner.

Strange i had to add a rule tha is not generating any traffic.

alt text

it is not generating any traffic but a big amount of evaluation.

I'll try later to disable it.

Other params are ok.

In the end I switched over to WireGuard - smashing it in around 6-8 MB/s. Tried everything with IPSec but gave up. I think I might have to investiage Wireguard further and switch the other VPNS over too.. The WireGuard seems to really forgiving of the StarLink latency/dropped packets.

Here is a file copy from a remote server to local along with 20x robocopy in the background doing file compares (no actual transfers)

FC.JPG wg.JPG

@bp81 I believe we have found the resolution, and I wanted to post it here for anyone else encountering the issue.

In our DNS forwarder, we had a domain override set for our company's domain. This is the same domain in the hostname for the remote gateway listed above. The domain override was pointing at a DNS server that is not accessible without the tunnel up. Clearly this was causing the IPSec service to fail repeatedly to establish its tunnel.

So there was a misconfiguration on our part which we have fixed. I still maintain that it's a bug if the ipsec service causes the web gui to crash / become unresponsive even when it's a self induced failure state due to misconfiguration. I understand it's possible this may be a limitation of the ipsec service, but it is worth looking at even if it is an edge case.

Bonjour,
je rencontre actuellement le meme probleme entre un pfsense et un fortinet. J'ai appliqué les propositions de gerdesj (hormis le reboot coté fortinet).
Pour le moment le probleme persiste.
Si quelqu'un a une idée.
Merci

Hello,
I currently encounter the same problem between a pfsense and a fortinet. I applied the proposals of gerdesj (apart from the reboot on the fortinet side).
For the moment the problem persists.
If someone has an idea.
Thank you

Oct 11 09:46:30 charon 55488 06[NET] <con100000|1> sending packet: from 10.10.10.254[500] to 84.14.183.243[500] (336 bytes)
Oct 11 09:46:30 charon 55488 06[IKE] <con100000|1> retransmit 1 of request with message ID 0
Oct 11 09:46:30 charon 55488 06[CFG] ignoring acquire, connection attempt pending
Oct 11 09:46:30 charon 55488 06[KNL] creating acquire job for policy 10.10.10.254/32|/0 === 84.14.183.243/32|/0 with reqid {1}
Oct 11 09:46:29 charon 55488 06[CFG] ignoring acquire, connection attempt pending
Oct 11 09:46:29 charon 55488 06[KNL] creating acquire job for policy 10.10.10.254/32|/0 === 84.14.183.243/32|/0 with reqid {1}
Oct 11 09:46:28 charon 55488 07[CFG] vici client 2 disconnected
Oct 11 09:46:28 charon 55488 07[CFG] vici client 2 requests: list-sas
Oct 11 09:46:28 charon 55488 07[CFG] vici client 2 registered for: list-sa
Oct 11 09:46:28 charon 55488 07[CFG] vici client 2 connected
Oct 11 09:46:26 charon 55488 06[NET] <con100000|1> sending packet: from 10.10.10.254[500] to 84.14.183.243[500] (336 bytes)
Oct 11 09:46:26 charon 55488 06[ENC] <con100000|1> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Oct 11 09:46:26 charon 55488 06[CFG] <con100000|1> sending supported signature hash algorithms: sha256 sha384 sha512 identity
Oct 11 09:46:26 charon 55488 06[CFG] <con100000|1> configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Oct 11 09:46:26 charon 55488 06[IKE] <con100000|1> IKE_SA con100000[1] state change: CREATED => CONNECTING

This was solved by missing GW on WAN interfaces

Ah, didn't spot this yesterday when I looked

https://redmine.pfsense.org/issues/11910

This can be considered solved I think.

Just for the record. Just loaded the cert onto a Yubikey 5 hardware smartcard. Same error/result.