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

@danielino1981 Assuming your mikrotik isn't dynamically generating a route for you, you will need to set a static route to 192.168.10.0/24

@jimp -Thanks for solution this seems to have resolved the connectivity issue. I have another issue which is causing IPSec to disconnect. Also ipsec service is not rebooting unless entire pfsense instance is rebooted. but it looks like different issue i'll troubleshoot and raise different thread if required. Thank you so much for the help.

Thank you for your reply. I upgraded our current pfsense 2.4.5 p1 to 2.5.0, but then ipsec connections don't work and there is nothing in Description tab of Phase 1 any more.

The PSK could be used to decrypt traffic if someone can capture packets between the endpoints. A weak key, in theory, could be brute forced. There is a lot of info around about this on the web by people much more familiar with the crypto than I. The PSK could also be used by someone in the right position to MITM or intrude over the VPN, but depending on your settings they would likely have to be able to intercept and spoof addresses in between for that to happen. If you have loose/weak P1 settings (e.g. your remote is "any"/0.0.0.0.0 for example) then the danger is increased. As above, weak keys could be brute forced. Using certificates is much more secure, as is using strict P1 settings to ensure only specific remotes can connect.

I figured that might be the case. The cloud provider doesn’t natively offer that. Would you have any recommendations on being able to run it on the pfSense box itself on the on-prem side?

I worked around the problem in this particular setup by using Routed (VTI) in the child SA. This was possible because there are pfSense on both sides. When using other VPN gateways, sometimes I can't use routed IPsec SA and then it would be nice when GRE over IPsec would just work. Kind regards, Mathias

@killmasta93 ping between FW doesn't work without extra actions. see: https://docs.netgate.com/pfsense/en/latest/recipes/ipsec-s2s-psk.html#pfsense-initiated-traffic-and-ipsec