Split tunneling in cOS Core with Windows L2TP/IPsec clients

Last modified on 29 Mar, 2023. Revision 17
A guide on how to set up split tunneling with cOS Core when using Windows L2TP/IPsec clients without requiring major changes on the client side
Up to date for
cOS Core 14.00.06
Supported since
cOS Core 10.x
Status OK
Author
Peter Nilsson


Problem Description

We have a scenario where a Windows L2TP/IPsec client is connecting to a NetWall firewall. However, we do not want to send everything through the VPN interface,which is default behavior in Windows L2TP/IPsec implementation (this is sometimes referred to as ‘Split Tunneling’). This article discusses a way to at least partially achieve split tunneling, depending on the network that the client wants to reach. A limitation of the method is that the network used will depend on the IP address that the client is assigned. This limitation is discussed further in the solution section below.

Note: Apple Mac clients seem to behave in the same way as Windows clients when it comes to assuming and adding routes based on the IP address received from the IP Pool. This article will, however, only go into detail with the Windows client.

Problem Solution

It is possible to solve the problem by using “partial” split tunneling. We describe it as “partial” because we will use the behavior in Windows where it tries to estimate the size of the network based on the IP address that the client gets from the L2TP server. Examples of how Windows sets the route based on the IP are the following:

  • If L2TP/IPsec client gets an IP address in the 192.168.x.x. range, Windows assumes a /24 network size.
  • If L2TP/IPsec client gets an IP address in the 172.16.x.x range, Windows assumes a /16 network size.
  • If L2TP/IPsec client gets an IP address in the 10.x.x.x range, Windows assumes a /8 network size.

We will assume that the L2TP/IPsec server is up and running using a standard setup. We will also assume that we have the corporate network setup illustrated by the following diagram:



What we want is that, depending on which client connects, they should only get access to Vlan_10 or Vlan_20’s network. All other traffic should use the client’s own internet connection and not be sent through the tunnel.

In this scenario we want Client-A to reach the Vlan_10 network only, and Client-B should only reach the vlan_20 network.

To accomplish this we need to give the two clients an IP address from the L2TP server that is part of the Vlan_10 and Vlan_20 network only. We accomplish this by giving each connecting client a static IP address in the network range they should have access to.

So Client-A will get an IP address in the 192.168.130.xx range and Client-B gets an IP in the 192.168.140.xx range. In this example we are using a local user database, so the option to do this can be found in the cOS Core WebUI under *System > Local User Database > database-name > user-name *



Note-1: This is also possible using Radius by setting a “Framed IP” on each user.
Note-2: The normal IP pool on the L2TP server can be used for normal users that do not use “split-tunneling”. They need to send everything into the tunnel though unless they want to reach the standard Pool network.
Note-3: We do not define any networks behind the user as that is something completely different and is not used in this scenario.

Once this is done we can configure the L2TP/IPsec client in Windows to NOT use the VPN tunnel for everything by removing the “Use Default Gateway On Remote Network” option on the VPN tunnel configuration.


Solution Limitations

  1. The main limitation is that we can not use multiple networks. One network only can be used and that network is part of the IP pool we give to the client.
  2. IP addresses needs to be reserved in the target network for the connecting clients.
  3. The network size varies heavily depending on what kind of IP we give to the client. It is recommended to examine the size of the network Windows assigns by using the "route print" command in Windows after a client has connected.
  4. Depending on if we want to allow reverse connections to the clients or not, we may have to enable ProxyARP or simply NAT the traffic to/from the target network.

Related articles

Configuring L2TP/IPsec Server using PSK
11 Jan, 2023 ipsec core vpn
Setup of a Layer-3 bridge over IPsec in cOS Core
12 Apr, 2023 core proxyarp arp ipsec routing
Configuring public certificates in NetWall firewalls
18 Mar, 2024 core certificate oneconnect ipsec vpn
cOS Core L2TP server setup with Windows Server CA certificates
21 Feb, 2023 ipsec certificate windows ca core
Problem with auto-created Core routes
22 Mar, 2021 core ipsec routing
Certificate update in InControl global domain on certificate that is used on firewall(s)
18 Mar, 2024 core incontrol certificate oneconnect ipsec vpn
Setting up OSPF with IPsec in cOS Core
16 Apr, 2024 core routing ospf ipsec
cOS Core IPsec IKEv1 "No_Proposal_Chosen" error in 14.00.10
4 Aug, 2023 core ipsec troubleshoot ike
IPsec license usage calculation
14 Apr, 2021 core license ipsec
Does IPsecBeforeRules trigger before Access rules?
8 Sep, 2020 core ipsec rules access
Troubleshooting IPsec tunnels (IKEv1)
7 Dec, 2022 ipsec ike troubleshoot core
cOS Core IKEv2 tunnel setup with certificates for iOS clients
5 Apr, 2023 core nps ipsec radius legacy
Freeing up more memory in the Firewall
23 Aug, 2022 core connections ipsec memory
Route failover with IPsec tunnels in cOS Core
13 Feb, 2023 ipsec core routing failover