Thank you kindly. I had the Version set to auto (ASA set to IKEv2) so it wasn't appearing. Trying to debug some L2L ipsec issues currently with multiple child SA.

2.1.4? Upgrade and ask again.

That's exactly what it was. ASA does not support sending multiple SAs in the same TS payload.

That tutorial is specifically for routing all the branch site traffic out the main site. Not the tutorial to use if you just want to connect the two sites. Change the phase 2's from 0.0.0.0/0 to the LAN subnet / subnet on the other side of the tunnel.

A few more things we have tried without success…

Adding a 1:1 NAT entry for this BINAT (this worked for OpenVPN but not IPSEC) Changing NAT-T between Force/Auto

Still no love no matter what.  We have to force add the routes on the Shrewsoft VPN client for the BINAT network and we can see the traffic coming into the IPSEC tunnel but no replies and no traffic hitting the LAN so it seems like NAT is not happening.  No entries in the firewall logs showing that this is blocked either.

Thank you so much! I'll get on it right away!

@rlrobs:

https://doc.pfsense.org/index.php/Advanced_IPsec_Settings

"Enable MSS clamping on VPN traffic: Enable MSS clamping on TCP flows over VPN. This helps overcome problems with PMTUD on IPsec VPN links. If left blank, the default value is 1400 bytes. This is useful is large packets have problems traversing the VPN, or if slow/choppy connections are observed across the VPN. Ideally it should be set on both sides, but traffic will have MSS clamping applied in both directions."

Change for 1350 and test

Hello, having the same problem here, and changing the MSS clamping to 1400, 1350 or even 1300 didn't change anything unfortunately.

As "feeling", it seems like in certain conditions the IPSec interface is limited to 10Mbps, or better, the communications between the IPSec interface are limited to 10Mbps, but this is just a feeling because I cannot find any limit anywhere.

Thanks,
Michele

Thanks for help me I attached th photos

1.png
1.png_thumb
2.png
2.png_thumb
3.png
3.png_thumb
4.png
4.png_thumb

Seems the SoftEther client is using SSTP to connect to Azure to make the connection back to my VPN server.  So it's not IPsec/L2TP connection really.  I have no issues connecting on port 443 to other web sites.  Real newbie question but what log(s) do I need to look at from the pfSense GUI to see my connection traffic/process?

For reference in what I'm trying to do:
https://www.softether.org/4-docs/2-howto/6.VPN_Server_Behind_NAT_or_Firewall/2.VPN_Azure

Thanks,

I did try 1350 as advised, no difference. 1300 also made no difference.

Are your systems in a domain environment?  If do you can push very via group policy.

I have the Same problem,

Hello Jimp,

This is a fresh build for a new office, so there aren't many FW rules as yet.  The IPsec S/S channel is essentially a copy of the Office3 stable IPsec S/S link, so nothing really exciting to see there.
VLAN3 has no specific host/port allow rules
Block rules to other VLANS/interfaces.
Allow all rule for internet.

VLAN3 is on LAGG0 along with 2 other VLANs (LAGG0 is 2x10GbE interfaces).

After stuffing around for another hour or so I gave up and rebuilt the unit from scratch last night.

I don't know what is going on but everything works fine this time around… I've compared the config.xml files and they are identical.

The problem is fixed but the issue is unresolved, guess we will never know.

Both IPsec and L2TP work fine on their own for their intended purposes, it's the combination that fails in that situation. It wouldn't be accurate to place a warning anywhere in the pfSense GUI as it wouldn't be directly relevant, thus the warning on the wiki.

Do you have any errors showing in the IPsec log when this happens?

What if you set your logs to the following values:  IKE SA, IKE Child SA, Configuration backend on Diag. All others on Control.
See also: https://doc.pfsense.org/index.php/IPsec_Troubleshooting#Common_Errors_.28strongSwan.2C_pfSense_.3E.3D_2.2.x.29

Additionally, rather than a reboot, try stopping the IPsec service and then starting it again. Don't use a restart as that only reloads the configuration.