@richi44 I setup 51 tunnels on Netgate XG-7100 but the problem remains. After Apply changes, which takes more than 4 min Time Out 504 error shows. Could you help me to solve this problem? This is really bad if I want to make quick changes to my tunnels. Thank you.

@jeffsmith82 Freeradius framed-ip addresses. https://forum.netgate.com/topic/115795/guide-ikev2-ipsec-per-user-firewall-rule-settings-with-freeradius

What is their network configuration and what is yours. Did they order a NAT at the source? On the computer below pfsense did you make the route for them? I already had to create an S2S where they gave me a subnet that I should do NAT at the source. Because any traffic on the VPN coming from another subnet was blocked.

@lamaz oh boy /me so sorry only openVPN with nomadic users in use here ip-sec only for site2site sorry

@christ what a strange behavior, after I restarted my PfSense I didn't have any problem related to IPsec or another thing, perhaps I did some incorrect configuration at that time. I'll update you guys if I have another problem related to this. Let me know if I can help you :) Regards, Christian

@metisit Still no progress as I am facing some other issues here. Honestly I start thinking to revert to normal static IPSec, but the fact that I won't have to step in in the middle of a "crisis" and let BGP do its job, keeps my faith to this configuration. As soon as I solve the other issue that I have, I will give it a shot. According to Netgate support, what I mention at the beginning is totally reasonable and can happen. I'll keep you posted. Chris

I figured out the problem - I set up BiNat between several firewalls and determined that the problem was issolated to just the one (new) implementation. Realized that the default LAN to any rule specified the LAN net as the source, changing that to "any" allowed traffic to flow.

I found the issue. I set the identifier of the public site to "My IP Address" and the remote identifier to any. Then I changed the remote address to an dyndns address of the CGNat Ip (public one, not the internal ip). On Site B I set the remote identifier to "Peer IP Address" and my identifier to DynDns with the dyndns hostname. Then everything worked fine....

Now resolved - a misconfigured Azure routing table was blocking the connection.

Now I have found following system log messages on my SG-3100: cesa1: TDMA descriptors pool exhaused. Consider increasing CESA_TDMA_DESCRIPTORS. Somebody saw something similar? Could be related to that here: Bug 226682 - ARMADA38X: Running out of CESA TDMA descriptors for disk I/O on GELI SSD

@sergio77 That's It! the problem has been solved? rekey happens every 54 minutes by default that's why the tunnel is UP for 1 hour (more or less)

From documentation: "Strict CRL Checking When set, the IPsec daemon requires availability of a fresh CRL for peer authentication based on certificate signatures to succeed. Primarily useful when the CRL is obtained dynamically (e.g. OCSP)." So what does "fresh" mean. From my point of view this should be a "Next Update" which is not in the past, no? Or should this only be used with OCSP and there is a static time after which we need a fresh CRL?

@metisit Hi, almost, Diagnostics/States/states and I manually removed the respective connections using the bin button.

Ok.. I have to set a failback "Virtual Address Pool" and check the Radius IP address priority checkbox. It work. I suppose that because the upgrade... anyway. By the way, i also have a Site2Site ipsec connection to anothse pfsense.. and it doent come up.. and when i click connect , it just refresh the page with " Collecting IPsec status information." but nothing else happen. I saw there were a fix for a similar problem already included in the 2.5.1.. anyway i will try to see it's another subject.