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.

@antonior NAT in IPSec is done in your Phase 2 config. see: https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configure.html#phase-2-settings and: https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/phase-2-nat.html

@viragomann thanks, the outbound NAT option has worked correctly.

@danjeman said in pfSense 2.5 to pfSense 2.5 IPsec tunnel fails to connect: @jimp Guessing the Dashboard display for QAT or other crypto modules didn't make it to 21.02.2 - at least my XG-7100's still show 'AES-NI CPU Crypto: Yes (inactive) - no mention of QAT anywhere that I can find on a Dashboard widget etc. It's there on 21.05 snapshots, didn't make it into 21.02.2.

@pete35 Thank you for the suggestion. But the problem was a typo in the identifier field in the Pre-Shared Keys tab.

Update on this - I disabled this tunnel in pfsense and created a new one by copy/pasting all settings, including the PSK, from the old tunnel to the new tunnel. I still cannot initiate connection from the pfsense side. There is nothing in the logs that indicates any attempt at creating a new tunnel, nothing referencing the far side IP - it's not doing a thing. But with the new tunnel, I can successfully initiate the tunnel from the far end. When I do this, there are two shown in Status -> IPSec - one that is connected, and one that is not. If I disable the new tunnel and re-enable the old tunnel and try to connect from the far side I get the same MAC mismatched failure again. Switch back to the new tunnel - with the exact same settings - and it works. Something's still not right. Anyone got any ideas? I'd sure like to be able to initiate from my end.

@rbritton You did add the correct remote network settings on the Phase2 entries right??[image: 1618506867802-remote_network.png]

@jd-0 Wanted to followup that 21.02.2 (as well as the RC over the last month) completely resolved my random drops issue. Many thanks!

@shpokas This thread got me going and then using the same troubleshooting commands I found I am missing "Virtual IPv6 Address Pool" for mobile IPSec config. Once I did that, all was good. How this was working before upgrade to 2.5.1 I have no explanation.

I have multiple IPsec in place. But only 1 mobile. For each site-to-site you need to create P1 and P2 like @keyser said.