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 [image: 1.png] [image: 1.png_thumb] [image: 2.png] [image: 2.png_thumb] [image: 3.png] [image: 3.png_thumb] [image: 4.png] [image: 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.

Hello, I have the very same problem as stated in the first post from "fabio.grasso" . From my understanding the IPSEC traffic should be intercepted before any routing is applied. And like this it is working in 5 of my 6 pfSense boxes, but not on one. All pfSenses are on 2.3.2 release and all routing and all IPSEC-tunnels are of the same kind (different ip-ranges of course). just box#6 makes this problem, resulting in a asymmetric routing, because it tunnel partner has not the problem. I disable the 10.0.0.0/8 route and traffic through the tunnel works, by adding it again the ipsec-routing is broken again…. I have no idea why it happens just on 1 box and it makes me abit nervous to see such an inconsistent behaviour. Thanks a lot for sharing a solution (Remote-IPSEC-Lan routing via "Null4 - 127.0.0.1") But should I apply this patch now alo to the working ones??? Kind regards Maddin

Hello, On pfSense you find this Option on the tunnelconfig: VPN/IPsec/ Tunnels/Edit Phase 1: ckeck the box "Disable rekey" to Disables renegotiation when a connection is about to expire. greez

Thank you. I was only looking at settings on pfsense and never questioned the client. I solved the issue and will explain below specifically for windows clients what the problem was. Windows 10 now defaults VPN connections with Split Tunneling set to true. Split tunneling selectively only routes traffic that matches your leased address over the tunnel, while routing all your other traffic out your local machines gateway. I believe that IKEv2 requires virtual addressing pool, which has to be on a separate subnet. So the default client settings will never successfully route any traffic except to other remote VPN clients. So IKEv2 on windows without custom settings will never function. There are a few solutions. 1. Disable split networking and route all traffic through the remote gateway. (Be sure on Phase 2 to set Local Network to 0.0.0.0 / 0 to route all traffic) 2. Keep split networking enabled, and add a custom route rule on the client to force traffic desired for the remote's lan traffic to use your VPN interface. (route add command) Windows 10 has broken the conventional UI menus to change the VPN settings under the VPN network adapter's networking tab. The old checkbox was "Use default gateway on remote network", which was previously enabled by default. This checkbox when enabled is the same as split tunneling set to false. The workaround is to use a powershell command to configure your VPN. In powershell you can list your VPN connections with the command: Get-VpnConnection With the name of the VPN connection you can disable split tunneling with the following command: Set-VpnConnection -name "connectionName" -SplitTunneling $False I'm surprised with how poorly VPN's are implemented on many devices.