---
title: Defining Split Tunneling Network Policies
slug: ps/help/en_us/ics/com/vtcg/defining-split-tunneling-network-policies
docTags: 
createdAt: 2026-08-02T15:43:23.685Z
---

Use the Split Tunneling Network tab to write a VPN tunneling resource policy that specifies one or more network IP address/netmask combinations for which the system handles traffic passed between the remote client and the corporate intranet. You can also specify traffic that should not pass through the VPN tunnel.

When split-tunneling is used, VPN tunneling modifies routes on clients so that traffic meant for the corporate intranet networks flow through the tunnel and all other traffic goes through the local physical adapter. The system tries to resolve all DNS requests through the physical adapter first and then routes those that fail to the VPN tunneling adapter.

For example:

- If split tunnel is disabled, all split tunnel configuration is ignored, including the exclude route. The default route goes to the tunnel allowing access to the protected network.
- Split tunneling is enabled and the included route contains 10.204.64.0/18 and the exclude traffic contains 10.204.68.0/24. In this scenario, networks from 10.204.64.0/18 to 10.204.127.0/18 will pass through the VPN tunnel with the exception of the 10.204.68.0/24 network, which will not pass through the VPN tunnel.
- If split tunneling is enabled and the include route contains 10.204.64.0/24 (subnet of the excluded route) and the exclude route contains 10.204.64.0/18 (super set of the included route) then the included network's traffic will still be routed through the VPN tunnel.

:::hint{type="info"}
If split tunneling is enabled and there are no include routes configured to be sent to the client, VPN tunneling adds a default route to send traffic through the tunnel.
:::

In addition to using subnets to define the traffic flow, the split tunneling resource policy supports a dynamic per session resource list based on user attributes. The authentication server can be any type, but must be able to pass user attributes during authentication or authorization. Below is one example scenario. The exact steps depend on your implementation and will vary from this example.

1. A user enters their credentials to initiate a session.
2. **Connect Secure** contacts the back-end authentication server, for example using a **RADIUS Access-Request&#x20;**&#x6D;essage.
3. The **RADIUS server** checks the policies and contacts other back-end resources (if configured) to authenticate the user and to retrieve parameters for the user session.
4. The **back-end server manager&#x20;**&#x6F;r **policy manager&#x20;**&#x73;ends the attribute list to the **RADIUS server&#x20;**&#x61;long with a list of **hosts** and **IP subnets**. Note that Steps 3 and 4 vary depending on your deployment.
5. The **RADIUS server&#x20;**&#x72;eturns the list of internal hosts and subnets to the system as part of the **RADIUS Access-Accept&#x20;**&#x6D;essage.
6. The system is configured with the split tunneling resource policy for that user session based on the received subnet information from the **RADIUS server&#x20;**&#x61;nd returns the policy to the client. The client uses this information to make the local split tunnel decisions.

   To write a split tunneling networks resource policy:

- In the **admin** console, choose **Users > Resource Policies > VPN Tunneling > Split-tunneling Networks**.
- On the **Connect Split Tunneling** page, click **New Policy**.
- On the **New Policy** page, enter:
  - A name to label this policy.
  - A description of the policy (optional).
- In the **Resources** section, specify:

:::hint{type="info"}
To know the maximum split tunnel networks supported per tunnel, refer the KB article [KB16725](https://forums.ivanti.com/s/article/KB16725?language=en_US) add in 22.5R2.1 Release.
:::

:::Paragraph{listStyleType="disc" indent="2"}
One or more **network IP address/netmask** combinations for which the system handles traffic passed between the remote client and the corporate intranet. You may also use the '/' (slash) notation to specify these networks.
:::

:::Paragraph{listStyleType="disc" indent="2"}
&#x41;**&#x20;user attribute**, for example \<userAttr.Framed-Route>, to send to the back-end authentication server.
:::

:::Paragraph{listStyleType="disc" indent="2"}
You can specify both **IP address/netmask** combinations and user attributes in the **Resources&#x20;**&#x73;ection.
:::

:::Paragraph{listStyleType="disc" indent="2"}
Please note the following:
:::

:::Paragraph{listStyleType="disc" indent="3"}
If a user attribute is configured in the resource list, it is dynamically resolved from the user session data.
:::

:::Paragraph{listStyleType="disc" indent="3"}
Invalid entries (including "\*") are ignored.
:::

:::Paragraph{listStyleType="disc" indent="3"}
If a configured user attribute is not resolved at runtime for the resource lists, the device acts as if split tunneling is disabled.
:::

:::Paragraph{listStyleType="disc" indent="3"}
**FQDN** (Fully qualified domain name) based split tunneling lets the admin configure split tunneling rules by directly specifying the domain names. This is helpful while configuring rules to ignore or tunnel cloud services. For **FQDN** resources wild card domains are be allowed.
:::

:::hint{type="info"}
FQDN supports IPv6 only on Windows , and IPv4 only on other platforms .
:::

:::hint{type="info"}
FQDN-based split tunneling supports dual stack (both IPv6 and IPv4) only on Windows, and not supported on other platforms.
:::

:::hint{type="info"}
FQDN based split tunneling only supported with IPv4 Traffic Enforcement feature enabled for the respective role.
:::

:::Paragraph{listStyleType="disc" indent="3"}
If duplicate IP address or netmask are added to resource policies it cannot be saved and you get an error message stating all the duplicate IPs. This feature is supported from 22.5R2.1 release.
:::

- In the **Roles** section, specify:
  - **Policy applies to ALL roles** - To apply this policy to all users.
  - **Policy applies to SELECTED roles&#x20;**- To apply this policy only to users who are mapped to roles in the Selected roles list. Make sure to add roles to this list from the Available roles list.
  - **Policy applies to all roles OTHER THAN those selected below -&#x20;**&#x54;o apply this policy to all users except for those who map to the roles in the **Selected roles** list. Make sure to add roles to this list from the **Available roles** list.
- In the **Action** section:
  - **Allow access&#x20;**- Network IP address/netmask combinations specified in the Resources list pass through the VPN tunnel.
  - **Exclude access&#x20;**- Network IP address/netmask combinations specified in the Resources list do not pass through the VPN tunnel.
  - **Use Detailed Rules (available after you click 'Save Changes')&#x20;**- Select this option to define resource policy rules that put additional restrictions on the specified resources.
- Click **Save Changes.**
- On the **Split Tunneling Policies** page, order the policies according to how you want to evaluate them. Keep in mind that once the system matches the resource requested by the user to a resource in a policy's (or a detailed rule's) **Resource** list, it performs the specified action and stops processing policies.
