@spearhead1 As you say that both phase 2 SA are connected, can you see packets going out when you go to Status / IPsec / Overview and click on + Show chiild SA entries? If not, can you see the unencrypted traffic coming from 10.225.172.0/24 in a packet capture? If yes, can you confirm that this is the right traffic by doing a packet capture on the IPsec interface?

@rex2020 as a quick workaround, i muted all logging controls by setting them to silent: [image: 1636650955367-a9470e32-0f66-44fc-a0b0-80d3faca2e9f-grafik.png]

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.