@RM85 image.JPG

In case anyone finds this thread while diagnosing the same problem. A fix is currently in development, and can be manually applied for testing now. Please see https://redmine.pfsense.org/issues/14396

Yes, it's been fixed in current development snapshots of CE 2.7.0 already, and in the most recent release of pfSense Plus software.

JFYI. I've ended up with adding two extra pfsenses (for HA) that deals with ISP channels only

I have also posted this problem in the NAT section with more information to see if someone can help me.

Thanks you

@Dobby_ said in IPSEC is insanely slow, Less that 1/10th speed:

This should be the bottleneck

At least, from B to A. 35 Mbps is about 4 MBps max, but OP says that's 3 so OK.

@calmasacow How is this test transfer happening? SMB is slow over VPNs unless it's using SMB 3, as I recall. Try FTP or another method if possible. (also Windows 11 has a bug in the May update causing very slow VPN performance but I'm pretty sure that's with Windows 11 itself as the VPN client)

@calical https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configure.html

recreated in a different order and now it works. first the phase2 without NAT and then the one with NAT.
Topic can be closed

Hard to say what that crash may have been but probably hit a bug in strongSwan more than anything.

It should be more stable on 23.05. Not only is it on a newer version of strongSwan, but the new version also fixes some locking issues that had sometimes caused charon to end up deadlocked.

@sunka said in Can't get IPSEC to connect, been trying for days.:

May 22 18:29:01 martin-Legion-5-15IAH7H charon: 16[ENC] parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
May 22 18:29:01 martin-Legion-5-15IAH7H charon: 16[IKE] received AUTHENTICATION_FAILED notify error

This suggests that part of your handshaking is wrong.
SSLs or keys or a mix of the two or whatever the config is.

@operaiter said in Portforwarding on WAN Interface via Site to Site IPsec:

I did just double checked the rule. Furthermore I did setup a new rule with different traget and port. Still cant see outgoing traffic on pfSense interface.

The only reasons for this apart from NAT and filter rules, I can think of, is that the tunnel is not working properly.

Possibly the additional phase 2 is not correct or not accepted. Some IPSec implementations may reject this multiple phase 2 for the same or overlapping subnets.
You can check out the log for hints due this.

Same story for me on pfSense+ 23.01. Tried everything until I came across this post, which amazingly works. My use case is to iOS 16.4.1.

@meluvalli For now, I ended up switching to WireGuard. I much prefer to use IPSec though. IPSec seems more stable of a connection. I really would like to get to the bottom of this :(

Seems this is a known limitation: https://forum.netgate.com/topic/118063/dhcp-relay-over-ipsec-vpn/16

I have solved the issue. The cause was on hoster's network and I had to manually add vpc routes to go via pfsense server for office networks CIDR.

Also need to add that there was no such issue when we for example use openVPN since it masks the IP and in normal IPsec we have to know exactly where to send packages to. Thus some extra steps have to be done.