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.

You can make Windows 10 use Group 14 as described here: https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#AES-256-CBC-and-MODP2048 Then do the same for IOS using the Apple Configurator 2 (https://support.apple.com/en-us/HT205285) and this tutorial: https://forum.pfsense.org/index.php?topic=106433.0 (Use Group 14 instead of 20, which is what this tutorial has)

Hi, thanks for that hint. Can I change them somehow? I think that solves my problem described here…. https://forum.pfsense.org/index.php?topic=119347.0 But I cannot simply change the SADs the ::0/0 part because the it should be some kind of policy based routing. I got a LAN with (lets say) 2001:fat:babe::/64 and a DMZ with (lets say) 2a01:face::/56 which "comes" with the IPSec Tunnel. Everything from the DMZ schould be routed via the IPSec Tunnel, thats why the SPDs are ::0/0 -> 2a01:face::/56  and 2a01:face::/56 ->  ::0/0. But If a packet arrives from the local Lan 2001:fat:babe::/64  it is not directly routed in the IPSec 2a01:face::/56 Network and never arrives there. I put up some static routes in the pfsense gui but that does not work - only in the moment the IPSec tunnel is stopped - then the local DMZ (without Uplink and set routes from Strongswan) it works…. but that does not really help:-) Would be nice if you got some further advice Thanks a lot! Cheers, 4920441

IPsec has a rule, the last one is "any to any on any GO!" lol

Pretty sure I answered this here: https://forum.pfsense.org/index.php?topic=119315.0

"Responder only" would do exactly as you described – When the VPN times out or the keys expire, it will not automatically establish again. Unset that on both sides.

Hello Derelict, thanks a lot for your answer! The guide specifies that the host name of the firewall has to be entered both in the CN and in a SAN with the type "DNS". Since the DNS option doesn't exit in 2.3.2-RELEASE-p1, I chose "FQDN or Hostname", but I had already done that before I created this topic. In fact, just to make sure I wasn't remembering it wrong, I redid the whole tutorial from scratch with the same result. Since I was following the tutorial that I linked to and not the one you linked to, I hadn't tried out disabling the EKU check, but that lead to the same result aswell. Regarding the import of the certificate, I again followed every step in the tutorial and I can see the certificate authority in the certificate store.

Figured this out for wopping 15 views and no reply. Add additional P2 tunnels for each VPN. RED WAS ADDED TO WORK PFsense (1.1.1.1/24): VPN1 to 1.1.1.1/24 (to me) local int <-> 192.168.10.0/24 192.168.50.0/24<-> 192.168.10.0/24 VPN2 to 1.1.1.1/24 (to user) local int <-> 192.168.50.0/24 192.168.10.0/24 <-> 192.168.50.0/24

Bump :) I just need PFsense to be the DHCP server to another FW.

Thanks for your replies, but the ranges are completely different so the subnet bit would be ridiculous LOL. Multiple P2's arent too bad.