Cool feature….

Start by adding the folloowing to your L2TP rules ipv4 UDP any destination port 1701 ipv4 destination local network subnet ipv4 not to local network subnet gateway WAN

IPsec does not add anything to routing table. Stop messing with routing tables. And of course with none of the  172.16.x.x networks configured in IPsec, this won't work. P.S. Instead of describing your setup in rather convoluted way, produce a network diagram.

It was removed because it was insecure. If the device on the other end is that old, it's likely doing them more harm than good as a firewall. If you search for the commit that removed DES support you could reverse the changes, but you'll have to look that up on your own.

I just thought I'd mention too that I'm not sure if it was the way that I performed the update that caused this, however, I was on the VPN connection when I performed the update.  Probably a bone-headed thing to do which I will definitely not repeat!  I also will not update without first: checking the release notes waiting for it to be around awhile to see if others have issues Not update without a full backup of the device ;D

Thanks Jon - I'll get them to confirm from their end and see if I can spot any misconfigurations. As a side note, it hasnt dropped since I posted this message, but there have been no configuration changes - so very strange :)

It seems that for IKEv2 I need to create a Server Certificate which needs to include the IP address of the server. Since my server has a dynamic public IP address, it seems that I cannot use IKEv2 after all. Is that right? Thanks, James

I was able to get it to work by doing the following (for any future readers). I have Windows 10 and wanted to use the built-in VPN for a number of reasons (VPN before logon, ease for users, etc) My pfSense mobile client is set up a EAP-RADIUS. I created a Powershell script: Add-VpnConnection -Name "VPN NAME" -ServerAddress xxx.xxx.xxx.xxx -AllUserConnection $true -SplitTunneling $true -AuthenticationMethod MSChapv2 -TunnelType Automatic -EncryptionLevel Required -PassThru Add-VpnConnectionRoute -ConnectionName "VPN NAME" -DestinationPrefix 10.20.1.0/24 Add-VpnConnectionRoute -ConnectionName "VPN NAME" -DestinationPrefix 192.168.1.0/24 You need to Add-VpnConnectionRoute for any of the subnets that you will access over the VPN.

I was actually able to get the issues resolved. Turns out for some odd reason, when I used Chrome it was saving the network settings, but not really saving them. I used Firefox and as soon as i re-saved the info, the tunnel came up and traffic was flowing.

You may have two addresses assigned to a single NIC interface (one public, one private) but this does not mean that you can route between them. In fact you will NOT be able to route between them. You need two interfaces to route or you need subinterfaces or VLANS (in a single interface configuration) where to assign the different IPs so that you can route traffic between them. Cheers.

I have updated all sites now with the latest version. Unfortunately some ipsec tunnels are operational others are not. The strange thing is that after re-starting the ipSec service a few times I lost some connections that were active and can not get them back without any changes in the configuration. Very strange.

That's all up to the client. They will either send all or send none. You can setup custom routing with powershell commands on the client side to nudge additional networks over, the server can't influence that.

Well the reason I ask is because on another thread I discovered I couldn't nat the gre tunnel to one of my spare up addresses behind my ASA. So I thought I had better double check here.

At the end we worked this around and changed the MTU of the target machines (SSH servers) as we can afford the MTU change there (differently than on pfsense).