0

I'm testing a setup using ASA to provide VPN over L2TP/IPSec PSK to support native IPSec clients such as iOS, Android, MacOS, Windows, etc.

The issue I'm running into is that when connected, the split-tunnels do not seem to be working as simultaneous public Internet access is lost. On Windows clients (using the DefaultRAGroup), going in to the IPv4 settings on the VPN connection and unchecking "Use default gateway on remote network", works to enable direct/split Internet access. However other clients do not have this option, and it seems like it should not be needed with a split tunnel configuration anyway.

This is a fairly simple topology: a local LAN at 10.0.2.0/24, and a VPN local pool in 10.0.4.0/24. Other than the Internet access, everything is working properly and as expected on all devices to reach hosts in the inside LAN... you just have to disconnect to reach the Internet, which isn't the intention.

I've tried using ASA 9.1, 9.9 and 9.12 and have the identical issue, so it would seem this is a config problem. I pulled this recipe from a saved configuration I used long ago, which would have been on ASA 7 or 8, and I'm fairly certain the split tunnels were working (though I do recall also having to uncheck the "default gateway" in the LT2P device's IPv4 settings in Windows).

Is there something obvious I'm missing here?

Relevant configuration below:

ip local pool pool_vpn 10.0.4.100-10.0.4.199 mask 255.255.255.0

object network SITE1_LAN
 subnet 10.0.2.0 255.255.255.0
 
object network SITE1_VPNClient
 subnet 10.0.4.0 255.255.255.0

access-list acl_vpn_split extended permit ip 10.0.2.0 255.255.255.0 10.0.4.0 255.255.255.0 

nat (inside,outside) source static SITE1_LAN SITE1_LAN destination static SITE1_VPNClient SITE1_VPNClient route-lookup

crypto ipsec ikev1 transform-set set_aes-256-hmac esp-aes-256 esp-sha-hmac 
crypto ipsec ikev1 transform-set set_aes-256-hma_trans esp-aes-256 esp-sha-hmac 
crypto ipsec ikev1 transform-set set_aes-256-hma_trans mode transport
crypto ipsec ikev1 transform-set set_aes-128-hma_trans esp-aes esp-sha-hmac 
crypto ipsec ikev1 transform-set set_aes-128-hma_trans mode transport
crypto ipsec security-association pmtu-aging infinite
crypto dynamic-map cdm_vpnclient 10 set ikev1 transform-set set_aes-256-hmac set_aes-256-hma_trans set_aes-128-hma_trans

crypto map cm_outside 65535 ipsec-isakmp dynamic cdm_vpnclient
crypto map cm_outside interface outside
crypto ca trustpool policy
crypto isakmp identity address 
crypto isakmp nat-traversal 30
crypto ikev1 enable outside
 
group-policy foogroup internal
group-policy foogroup attributes
 vpn-idle-timeout none
 vpn-tunnel-protocol ikev1 l2tp-ipsec 
 password-storage enable
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value acl_vpn_split
 default-domain value foo.local
 intercept-dhcp enable
dynamic-access-policy-record DfltAccessPolicy

tunnel-group DefaultRAGroup general-attributes
 address-pool pool_vpn
 authentication-server-group (outside) LOCAL
 default-group-policy foogroup
tunnel-group DefaultRAGroup ipsec-attributes
 ikev1 pre-shared-key xxx
tunnel-group DefaultRAGroup ppp-attributes
 authentication ms-chap-v2

tunnel-group foogroup type remote-access
tunnel-group foogroup general-attributes
 address-pool pool_vpn
 default-group-policy foogroup
tunnel-group foogroup ipsec-attributes
 ikev1 pre-shared-key xxx

1 Answer 1

2

Perhaps the client does not properly support split tunnel by default? You should start by checking the routes on the client after the VPN is connected to determine whether it was given a route specifically for only 10.0.4.0/24 or just given a new default route.

In the case of the Windows built in client, I believe you do have to uncheck that default gateway option. All the guides I have seen for that software mention it.

https://www.cisco.com/c/en/us/support/docs/ip/layer-two-tunnel-protocol-l2tp/200340-Configure-L2TP-Over-IPsec-Between-Window.html

1
  • I think you're on to something there. On the native Android VPN client, under advanced options -> Forwarding routes, I put in the LAN subnet (10.0.2.0/24) and that did the trick to enable IPv4 internet access (public IPv6 does not work while connected though). More research needed as to whether or not needing to manually entering that route is a limitation of the native client or a configuration option still needed. Good confirmation about the Windows client required to uncheck that box, and not something I'm doing wrong!
    – 640KB
    Commented Mar 30 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.