https://forum.netgate.com/topic/163221/constraint-check-failed-rule_crl_validation-is-stale-but-requires-at-least-good/3 Same issue as this one, which had no responses. @lst_hoe

@periko I would like to know if it is planned to add route pushing to Windows clients using DHCP option? Thanks.

@jimp I'd love to see an opinion from Netgate about this scenario when you got some time; can't be that I'm the only one running site to site IPsec tunnels with dynamic IPs and FQDNs as identifiers.

@rai80 Thank you - I saw that bug report but still couldn't get things working. However, on this thread @stephenw10 answered a general query I had about PMTUD not appearing to work. It seems that PMTUD with policy-based IPSec does not work, but it does work with route-based IPSec. In my case, I have been using a policy-based IPSec tunnel. As soon as I set up route-based IPSec (with static routes at the moment, but I'm sure BGP will work too) then my RADIUS/EAP-TLS issue disappeared - and with scrubbing enabled (i.e. default pfSense settings).

@tomwork Thank you for sharing this great script, we have the same problem with the AWS tunnels ;-) We have a CARP HA setup and wanted to have it on both nodes. Therefore we need a check, that the script only starts down tunnels only if the CARP state is MASTER and is not active on the BACKUP node. Here it is - there may be better solutions but it works #!/bin/sh # check for MASTER master=`ifconfig | grep "carp: MASTER"` if [ -z "$master" ]; then echo "CARP Backup => exit script" exit; fi echo "CARP Master verifying IPSec tunnels..." tunnels=$( /usr/local/sbin/ipsec statusall | /usr/bin/grep dpddelay | /usr/bin/cut -d':' -f1 | /usr/bin/tr -d ' ' ) for i in $tunnels; do if /usr/local/sbin/ipsec status $i | /usr/bin/grep -q 'no match'; then echo "tunnel $i down" /usr/local/sbin/ipsec up $i fi

Much obliged !

@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 [image: oC3sEPA.png] 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. [image: Z2F2FjI.png] 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) [image: 1634368161001-fc.jpg] [image: 1634368165462-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.