IKEv2 Client Routing On Windows Issue



  • Hello,
    I followed this guide to setup my IKEv2 VPN:
    https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2

    I made a few tweaks to the algorithms and tweaked the PHP to insert the following value in ipsec.conf for iOS 9 to work:
    leftsendcert = always

    I've tried setting my leftsubnet to the following:
    0.0.0.0/0

    When using Windows, all traffic is bypassing the VPN. Using iOS 9, all connections fail.

    I then set the following leftsubnet:
    192.168.2.0/24

    Using iOS 9, that works as expected and I can access my internal network. On Windows, the connection fails unless I manually add a static route to use the VPN for that subnet.

    Do you have any ideas on how to make this work on Windows without specifying a static route on the client?

    Thank you for all of your help!



  • You'll need 2.2.5 for iOS 9 to work. Best off there for anything along these lines at this point, and release is near, should be later this week.



  • I am also trying to setup iOS 9.1 to be able to connect to our 2.2.4 router's IKEv2 Mobile VPN.

    The VPN does connect once I have leftsendcert=always, unfortunately I cannot access anything through the VPN. All internet traffic get routed as if VPN is not connected at all. None of the networks on the VPN are reachable. This is with leftsubnet=0.0.0.0/0, if I specify the LAN network, then I can reach address on the LAN.

    I have read this:
    https://wiki.strongswan.org/projects/strongswan/wiki/IOS_(Apple)#IKEv2-on-iOS-9-OS-X-1011-and-newer

    Everything looks like it should, but traffic does not go through the tunnel unless a specific network is set for leftsubnet, it's like the default route of 0.0.0.0/0 is not announced.

    Were there any other fixes in 2.2.5 other than this one for iOS 9?:
    https://redmine.pfsense.org/issues/5353



  • Nevermind I found this:
    https://redmine.pfsense.org/issues/5327

    Looks like things should work in 2.2.5



  • @cmb:

    You'll need 2.2.5 for iOS 9 to work. Best off there for anything along these lines at this point, and release is near, should be later this week.

    Thanks a lot for the information. Do you have any idea why Windows wouldn't be routing through the VPN without a static route?



  • @Cosmo_Kramer:

    @cmb:

    You'll need 2.2.5 for iOS 9 to work. Best off there for anything along these lines at this point, and release is near, should be later this week.

    Thanks a lot for the information. Do you have any idea why Windows wouldn't be routing through the VPN without a static route?

    I would assume it has to do with the bug they fixed that I mentioned, look at the diff:
    https://redmine.pfsense.org/projects/pfsense/repository/revisions/f3ee8205e6332d4895e93f4f2831cc65ab98d0c0/diff/etc/inc/vpn.inc

    Here is a description of the Attr Plugin that is mentioned in the diff that creates strongSwan.conf:
    https://wiki.strongswan.org/projects/strongswan/wiki/Attrplugin

    According to this doc the "subnet" attribute is "The protected sub-networks that this edge-device protects (in CIDR notation)". I believe this tells the client what networks are accessible via the tunnel.  Before 2.2.5 and the code change mentioned above, pfSense would just stick the VPN address pool into this attribute, which pretty much means nothing but the VPN clients themselves are accessible. After the the code change it actually uses the network that you specify in the Phase 2 settings, which should result in correct routing.

    It appears that the "split-include" Cisco Unity extensions attribute (which correctly used Phase 2 settings) in only used for IKEv1 and not IKEv2. So checking "Provide a list of accessible networks to clients" for IKEv2 is mostly useless.



  • @ltctech:

    @Cosmo_Kramer:

    @cmb:

    You'll need 2.2.5 for iOS 9 to work. Best off there for anything along these lines at this point, and release is near, should be later this week.

    Thanks a lot for the information. Do you have any idea why Windows wouldn't be routing through the VPN without a static route?

    I would assume it has to do with the bug they fixed that I mentioned, look at the diff:
    https://redmine.pfsense.org/projects/pfsense/repository/revisions/f3ee8205e6332d4895e93f4f2831cc65ab98d0c0/diff/etc/inc/vpn.inc

    Here is a description of the Attr Plugin that is mentioned in the diff that creates strongSwan.conf:
    https://wiki.strongswan.org/projects/strongswan/wiki/Attrplugin

    According to this doc the "subnet" attribute is "The protected sub-networks that this edge-device protects (in CIDR notation)". I believe this tells the client what networks are accessible via the tunnel.  Before 2.2.5 and the code change mentioned above, pfSense would just stick the VPN address pool into this attribute, which pretty much means nothing but the VPN clients themselves are accessible. After the the code change it actually uses the network that you specify in the Phase 2 settings, which should result in correct routing.

    It appears that the "split-include" Cisco Unity extensions attribute (which correctly used Phase 2 settings) in only used for IKEv1 and not IKEv2. So checking "Provide a list of accessible networks to clients" for IKEv2 is mostly useless.

    Perfect. Thanks for the detailed explanation. I'll post back after updating.



  • @ltctech:

    @Cosmo_Kramer:

    @cmb:

    You'll need 2.2.5 for iOS 9 to work. Best off there for anything along these lines at this point, and release is near, should be later this week.

    Thanks a lot for the information. Do you have any idea why Windows wouldn't be routing through the VPN without a static route?

    I would assume it has to do with the bug they fixed that I mentioned, look at the diff:
    https://redmine.pfsense.org/projects/pfsense/repository/revisions/f3ee8205e6332d4895e93f4f2831cc65ab98d0c0/diff/etc/inc/vpn.inc

    Here is a description of the Attr Plugin that is mentioned in the diff that creates strongSwan.conf:
    https://wiki.strongswan.org/projects/strongswan/wiki/Attrplugin

    According to this doc the "subnet" attribute is "The protected sub-networks that this edge-device protects (in CIDR notation)". I believe this tells the client what networks are accessible via the tunnel.  Before 2.2.5 and the code change mentioned above, pfSense would just stick the VPN address pool into this attribute, which pretty much means nothing but the VPN clients themselves are accessible. After the the code change it actually uses the network that you specify in the Phase 2 settings, which should result in correct routing.

    It appears that the "split-include" Cisco Unity extensions attribute (which correctly used Phase 2 settings) in only used for IKEv1 and not IKEv2. So checking "Provide a list of accessible networks to clients" for IKEv2 is mostly useless.

    So the update fixed my IOS 9 issues. I was still getting routing issues on Windows where the only route using the VPN connection was the Virtual IP subnet I had defined in pfSense. I was able to get everything to route through the VPN by using the following PowerShell command:

    
    Set-VpnConnection -Name 'NameOfVpnConnection' -SplitTunneling $false
    
    

    Thanks for your help.



  • That's really odd, considering that split tunneling in Windows is not a default setting and has to be enabled per VPN connection. Did you enable it earlier and forgot about it?

    Prior to Windows 10 it used to be a check box in TCP/IP IPv4 settings, in Windows 10 it's exclusively a PS command, not sure what MS is thinking.



  • @ltctech:

    That's really odd, considering that split tunneling in Windows is not a default setting and has to be enabled per VPN connection. Did you enable it earlier and forgot about it?

    Prior to Windows 10 it used to be a check box in TCP/IP IPv4 settings, in Windows 10 it's exclusively a PS command, not sure what MS is thinking.

    I am running Windows 10, and I didn't enable split tunneling previously. I wonder what could have caused it.



  • @Cosmo_Kramer:

    @ltctech:

    That's really odd, considering that split tunneling in Windows is not a default setting and has to be enabled per VPN connection. Did you enable it earlier and forgot about it?

    Prior to Windows 10 it used to be a check box in TCP/IP IPv4 settings, in Windows 10 it's exclusively a PS command, not sure what MS is thinking.

    I am running Windows 10, and I didn't enable split tunneling previously. I wonder what could have caused it.

    I just setup an ikev2 connection on my Win10 Surface 3 Pro and tested it at a friends house over his wifi.  The iPhone connects and works fine, but while the Windows PC connects, all traffic goes through the local wifi - not the VPN.

    I am back home now and just saw this thread and checked my setting using Get-VpnConnection and it seems mine is set to split tunneling!
    SplitTunneling        : True
    I DEFINITELY did not set it to true.

    C:\Users\davros>powershell
    Windows PowerShell
    Copyright (C) 2015 Microsoft Corporation. All rights reserved.
    
    PS C:\Users\davros> Get-VpnConnection -Name 'home ikev2'
    
    Name                  : home ikev2
    ServerAddress         : <myserver>.com
    AllUserConnection     : False
    Guid                  : {2AED2628-F1E4-43FF-920D-FB4E26D37064}
    TunnelType            : Ikev2
    AuthenticationMethod  : {Eap}
    EncryptionLevel       : Required
    L2tpIPsecAuth         :
    UseWinlogonCredential : False
    EapConfigXmlStream    : #document
    ConnectionStatus      : Disconnected
    RememberCredential    : True
    SplitTunneling        : True
    DnsSuffix             :
    IdleDisconnectSeconds : 0</myserver> 
    

    This is the settings for my PureVPN connection on the same PC…as you can see, it's set to false.

    PS C:\Users\davros> Get-VpnConnection -Name 'pureVPN'
    
    Name                  : pureVPN
    ServerAddress         : s050105.pointtoserver.com
    AllUserConnection     : False
    Guid                  : {EA9CBF5A-1F0B-4931-B6BA-99CDFF97D10A}
    TunnelType            : Pptp
    AuthenticationMethod  : {Chap, MsChapv2}
    EncryptionLevel       : NoEncryption
    L2tpIPsecAuth         :
    UseWinlogonCredential : False
    EapConfigXmlStream    :
    ConnectionStatus      : Disconnected
    RememberCredential    : False
    SplitTunneling        : False
    DnsSuffix             :
    IdleDisconnectSeconds : 0
    
    

    This now routes correctly from the PC.  Solved.



  • I've just updated to Pfsense 2.2.5 and setup the native Windows 10 IKEv2 VPN as per the instructions on this page (https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2)

    I can establish the VPN connection correctly but the routes to my phase2 destinations are not being added to my Windows 10 routing table. I need to manually add them with a simple batch command after I've established the connection.

    #Add Routes For VPN
    route ADD 192.168.1.0 MASK 255.255.255.0 192.168.11.255
    route ADD 192.168.5.0 MASK 255.255.255.0 192.168.11.255
    route ADD 192.168.10.0 MASK 255.255.255.0 192.168.11.255
    

    Once I've manually added the routes I can get to all the remote networks.

    Does anyone know how I can get the routes added automatically in Windows 10 once the VPN is established?



  • @Wasca:

    I've just updated to Pfsense 2.2.5 and setup the native Windows 10 IKEv2 VPN as per the instructions on this page (https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2)

    I can establish the VPN connection correctly but the routes to my phase2 destinations are not being added to my Windows 10 routing table. I need to manually add them with a simple batch command after I've established the connection.

    #Add Routes For VPN
    route ADD 192.168.1.0 MASK 255.255.255.0 192.168.11.255
    route ADD 192.168.5.0 MASK 255.255.255.0 192.168.11.255
    route ADD 192.168.10.0 MASK 255.255.255.0 192.168.11.255
    

    Once I've manually added the routes I can get to all the remote networks.

    Does anyone know how I can get the routes added automatically in Windows 10 once the VPN is established?

    The only thing I can think of is maybe advertising the routes via DHCP. Not sure if that'd work though.



  • When you have split tunneling enabled in Windows 10 you can add a VPN connection route for an IPv4 address. The route will only be set when the VPN connection is active (see https://technet.microsoft.com/en-us/library/dn262649.aspx).

    Windows PowerShell Example:
    Add-VpnConnectionRoute -ConnectionName "Contoso" -DestinationPrefix 176.16.0.0/16 -PassThru

    Windows PowerShell Enable Split Tunneling:
    set-vpnconnection Contoso -splittunneling $True

    Works like a charm.

    Philipp



  • @Philipp26:

    When you have split tunneling enabled in Windows 10 you can add a VPN connection route for an IPv4 address. The route will only be set when the VPN connection is active (see https://technet.microsoft.com/en-us/library/dn262649.aspx).

    Windows PowerShell Example:
    Add-VpnConnectionRoute -ConnectionName "Contoso" -DestinationPrefix 176.16.0.0/16 -PassThru

    Windows PowerShell Enable Split Tunneling:
    set-vpnconnection Contoso -splittunneling $True

    Works like a charm.

    Philipp

    Nice find, thanks for posting!



  • This problem still occurs as today with 2.3-RELEASE.

    Any other workarounds for publishing the Phase2 routes accordingly on Windows?



  • … and it seems like the problem is spanning over the complete Windows 10 Platform including mobile devices.
    And since there is no Shell on the phone to configure routes it's effectively kinda broken. I even looked into Windows 10 Provisioning tools but no configurable VPN routes there....


  • Rebel Alliance Developer Netgate

    That is all up to the client on Windows. Nothing pfSense or the server can do.


Log in to reply