@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??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.

@steveits Thanks for your reply. I am aware of the changes. I was initially on 2.4.5, then went to 21.02-p1, and am currently on 21.02.2.

As mentioned, the issues started after the 'upgrade' from 2.4.5. But a few details that I will add since I was thinking back:

Very rarely, the speed on transfers does go up to the expected speed of around 40 MB/s and lasts a few minutes, but then returns to the around 8 MB/s. Unfortunately didn't catch the logs when this happened.

Also, the logs look normal, just the dashboard checking the IPsec status in the normal fashion.

CPU usage does rise when Async is turned off, but speeds stay basically the same regardless.

The issue is not like what is mostly mentioned by others, where the tunnel does not stay active. Mine does stay active, and is rather stable, its just that the speed is much slower than previous, with the same settings.

You can just update, the patches are a part of 21.02.2/2.1.5.

Alternately, you can remove the patch entries (Do NOT revert, just delete them) either before or after upgrade and leave the patches package in place.

The only possible action you might need to take is to make sure none of them are set to auto-apply. In most cases that wouldn't hurt anything since it would just fail to apply, but certain diffs may end up adding themselves multiple times that way.

@vishal-mhatre2310 Sorry for the late response. Do you still need help here?

@gertjan said in pfsense 2.4.5-RELEASE-p1 - Cisco - constraint check failed: identity IP:

Cisco - constraint check failed: identity IP:

for IKE2 ->constraint check failed: identity IP
i the same for IKE1-> IDir 'firepower' does not match to 'X.X.X.251'

@bingo600
Your thought about gateway prompted me to look over the config and compare with input from my ISP.

my primary IPv4 Upstream gateway was empty. I am not sure why it only worked temporary, when I closed the OpenVPN connection, it might be a route going wrong, like with a missing default gateway .

right now it looks stable :)

Thanks for the input

Update:
So I found this page finally this morning:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/ipsec.html

The Connection Hangs section perfectly describes my problem, however I have made many adjustments to the Maximum MSS and have not been able to stabilize the connection. It has improved, but has not gone back to working flawlessly despite trying many values. Does anyone have any advice or insights? Thanks.

We have the same problem in our company, considering multiple VTI Tunnels which randomly lose connection and never come back until someone triggers a restart.

"11[CFG] trap not found, unable to acquire reqid 2000"

Tried resolving it with TAC but to no avail. Enabling APIPA didn't change anything. I'm not sure where the problem lies but I'm guessing the VPC is refusing to route 169.254.x.x as it's strictly speaking not within a defined VPC route. I've noticed in another issue that any packet with an RFC1918 target ip without a defined route and an available target instance or VPN route with that RFC1918 range gets blocked straight after egress from the vm instance.

Traffic from pfsense LAN networks works flawless but the reason I need a ping from pfsense is because I'm running a blackbox_exporter on pfsense to monitor the IPSec tunnel by pinging the remote GC vm instance.

I worked around it by adding a VPC route to pfsense LAN1/32 address with the tunnel as gateway allowing only ICMP and added a blackbox_exporter icmp config with the LAN1/32 ip as source_address. That way the ping requests arrives at the GC instance with LAN1/32 source ip and the reply gets accepted because there's a defined VPC route and gets send through the tunnel.

Gr.