Pfsense 2.2.4 - split-tunneling using windows clients - missing route to vpn
-
Hey Jimp or whoever else sees this! I changed to a new thread since your steered me to a new idea vpn wise. (greatly appreciated)
I now have setup ipsec using ikev2, and eap-mschapv2 following the guide on pfsense.org (thank you doc folks!)
I alter the vpn connection on windows 8.1 and uncheck the route to remote gateway, which should allow split tunneling if I understand properly. IPSEC on pfsense 2.2.4 is set to provide a virtual address 192.168.250.x which is known to not conflict with any users remote networks.This leaves mobile windows 8 clients using their own ISP for internet access, and a connected vpn to the office, EXCEPT, their is no route added to the windows clients for 10.0.0.0/8 network in the office.
I can add that using route add 10.0.0.0/8 192.168.250.x but the problem is that the 192.168.250.x address is virtual and will change!
so even -p (persistent) route doesn't help here.I can't imagine I am the only one wanting to do this, and feel I must just be missing something simple.
I really would prefer to make this work without adding .cmd files to add the route manually.Can someone please help me out here with some ideas??
thanks, scott
-
We looked this over via the support ticket system, but I'll respond here as well:
Looking over the IPsec daemon documentation it appears what you are after may not be possible in a way that is both usable and desirable. It's a limitation of the Windows VPN client and not pfSense or IKEv2. The Windows client has no mechanism to receive routes/subnets over IKEv2 other than the VPN tunnel network itself. Unfortunately that's how the Windows client has always worked even with PPTP.
With "Use default gateway on remote network" unchecked all it will do is forward traffic for the VPN subnet itself, in your case, 192.168.50.x. Trying to fake that out by supplying the LAN network for the VPN tunnel network had issues as well and was not viable.
So it seems there are few choices here, none of which are all that good:
-
Let it tunnel all across the VPN while the clients are connected (and keep blocking Internet access) – this is the most secure choice, though not terribly convenient
-
Manually add the route to accomplish the split tunneling, which is also not very convenient
-
Use a different VPN type/client that does properly support split tunneling (e.g. OpenVPN, Shrew Soft perhaps using xauth, etc)
-
If all the clients are Windows 8.1 or later you might be able to rig something up with Windows Powershell cmdlets:
https://technet.microsoft.com/en-us/library/dn262649.aspx
If you want to stay with IPsec, what you are trying to do should work fine with the Shrew client and an xauth style IPsec VPN ( https://doc.pfsense.org/index.php/IPsec_Road_Warrior/Mobile_Client_How-To ). OpenVPN works excellently for split tunnel VPNs and may be a better way forward ( https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server )
-
-
Is there a working config for Shrew Soft (happy to router all without split tunnel) that works with Windows 8.1 / 10?
I have a working config that's fine with iOS, Windows 7 etc
It appears to be a routing issue, even adding the route via Shew Soft doesnt seem to help (It shows the route in Shrew VPN trace but there is no published route in the OS
-
W10? Don't think it works there at all…
-
On windows 8.1 and 10 you use powershell to allow this. checking or unchecking the use default gateway does not work for me. below has worked flawlessly for me on over 40 laptops which connect remotely that are using windows 10.
Add-VpnConnection -Name "NameofVPN" -ServerAddress "pfsense.domain.com" -TunnelType IKEv2 -EncryptionLevel Required -AuthenticationMethod EAP -SplitTunneling -AllUserConnection
Add-VpnConnectionRoute -ConnectionName "NameofVPN" -DestinationPrefix "Remote subnet"/24 -PassThru
replace RemoteSubnet with 192.168.1.0 (Ex) or what ever your remote subnet is.
-
With "Use default gateway on remote network" unchecked all it will do is forward traffic for the VPN subnet itself, in your case, 192.168.50.x. Trying to fake that out by supplying the LAN network for the VPN tunnel network had issues as well and was not viable.
What issues are this? I've seen an old (Debian) PPTP daemon config where exactly this was done. I'm just curious. Is this possible because it's a point-to-point link? Is there any arp proxying required?
-
There would be no ARP request, and it is not bridged.
The PPTP method used to work on pfSense as well because it faked the ARP step. While it may also be possible to fudge this with a proxy ARP VIP on pfSense matching the size of the IPsec subnet, it's ugly and you'd have to be careful not to step on the mobile client range with statics or local DHCP clients.
-
Thank you for your quick reply. Had the same problem scottzech posted and I will probably use OpenVPN now.
