About Split Tunneling Role Options
The following figure shows an unprotected network that contains the endpoint client and other unprotected resources, and a protected network that contains networks that can only be accessed through a VPN tunnel through Ivanti Connect Secure.
Before a VPN tunnel is created, there are three types of endpoint routes.
- Directly-connected subnet routes-Hosts on the directly-connected subnet can be reached without forwarding through a router. The ability to access these hosts is defined as local subnet access. 192.168.0.0/24 is an example of a directly-connected subnet route.
- Indirectly-connected subnet routes-These routes that have an explicit non-direct entry in the route table. Traffic must go through a router. 10.10.0.0/24 is an example of an indirectly-connected subnet route.
- Default route-this route if the destination is neither a direct-connected or indirect-connected subnet route. 0.0.0.0 is an example of a default route.
Enabling Split Tunneling
Options on the Users > User Roles > Role Name >VPN Tunneling page determine how the endpoint routes are modified when the VPN tunneling is established.
Split Tunneling options are:
- Enable - Adds or modifies routes for specific subnets to go to the tunnel, allowing access to the protected subnets. Subnets are defined in the Users > User Roles > Role-Name > VPN Tunneling > Options window. In the case of subnet overlap (the specified split-tunnel subnet conflicts with an existing endpoint route), the Route Precedence option is used. For example, 2.2.2.0/24 goes through the tunnel. 10.10.0.0/24 is both a split-tunnel subnet and an indirectly-connected subnet. The Routing Table, defined below, defines how 10.10.0.0/24 is handled.
- Disable - Modifies the default route to go through the tunnel, allowing access to the protected network. For example, 0.0.0.0 now goes through the tunnel.
- These settings apply only to systems with Split Tunneling enabled.
- These settings do not apply to third-party clients.
- Windows 8 (and later) will send a DNS request to only one interface. So, for Windows 8+ clients, selecting the first radio button sends DNS requests to the client's DNS only, whereas clicking either the second or third radio button sends DNS requests only to the gateway's DNS.
- For IP based Split Tunneling on Windows 8.1 machine, the DNS requests are sent to both the IVE and the Client DNS servers at the same time due to the limitation in platform API.
- For IP based Split Tunneling on Windows 10 machine, the DNS requests are sent to the IVE DNS server first and then sent to the Client DNS servers, irrespective of the DNS search order configured (1st or 2nd radio button).
- For FQDN based Split Tunneling, the DNS requests are sent to the IVE DNS servers only(3rd radio button), irrespective of the option selected.
- OSX does not support sending DNS requests to only the Ivanti gateway's DNS. So, for OSX clients, clicking the third radio button will have the same effect as the second button.
- For Windows Phone and Windows machines running the In-Box VPN client, checking the third radio button sends all DNS requests to only the Ivanti gateway's DNS. Having either other button checked causes only DNS requests matching the DNS domains (listed above) to go to the gateway's DNS, and all other requests go to the client's DNS.
Defining the Route Precedence Options
The Route Precedence option determines how the directly-connected subnet routes and the indirectly-connected subnet routes are modified. This depends on whether split-tunneling is enabled.
If split tunneling is disabled:
- Tunnel routes have precedence-Both directly-connected subnet routes and indirectly-connected subnet routes go through the tunnel. Endpoints lose access to the unprotected subnets.
- Endpoint routes have precedence-Neither directly-connected subnet routes nor indirectly-connected subnet routes go through the tunnel.
- Tunnel routes with local subnet access-Similar to the tunnel routes have precedence option except that directly-connected subnet routes do not go through the tunnel. Stated another way, tunnel all traffic except for traffic that is destined for the local subnet. This allows endpoints to access the local subnet.
If split tunneling is enabled:
- Non-overlapped subnets are added to the route table. For example, 2.2.0.0/24 goes through the tunnel. See figure in About Split Tunneling Role Options.
- Overlapped subnets have 2 options:
- Tunnel routes have precedence - These routes are modified to go through the tunnel and endpoints lose access to the unprotected overlapped subnet. For example, 10.10.0.0/24 goes through the tunnel. See Figure 145.
- Endpoint routes have precedence - These routes do not go through the tunnel. For example, 10.10.0.0/24 does not go through the tunnel. See figure in About Split Tunneling Role Options.
The following table summarizes how split tunneling and route precedence works with directly-connected subnet routes, indirectly-connected subnet routes, and default routes.
Split Tunnel and Route Precedence
Split Tunnel | Route Precedence | Direct Endpoint Route | Indirect Endpoint Route | Default Endpoint Route | Split Tunnel Policy Routes |
|---|---|---|---|---|---|
Disabled | Tunnel | Goes through tunnel. | Goes through tunnel. | Goes through tunnel. | NA |
Disabled | Tunnel with local subnet access | Does not go through tunnel. | Goes through tunnel. | Goes through tunnel. | NA |
Disabled | Endpoint | Does not go through tunnel. | Does not go through tunnel. | Goes through tunnel. | NA |
Enabled | Tunnel | Routes are modified to go through the tunnel only if they overlap with the split-tunneling subnets. Otherwise the routes do not go through the tunnel. | Routes are modified to go through the tunnel only if they overlap with the split-tunneling subnets. Otherwise the routes do not go through the tunnel. | Does not go through tunnel | New routes are added to go through the tunnel. |
Enabled | Tunnel with local subnet access | Does not go through tunnel. | Routes are modified to go through the tunnel only if they overlap with the split-tunneling subnets. Otherwise the routes do not go through the tunnel. | Does not go through tunnel. | New routes are added to go through the tunnel. |
Enabled | Endpoint | Does not go through tunnel. | Does not go through tunnel. | Does not go through tunnel. | New routes are added to go through the tunnel. |