Defining Split Tunneling Network Policies

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.

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 message.

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 or policy manager sends the attribute list to the RADIUS server along with a list of hosts and IP subnets. Note that Steps 3 and 4 vary depending on your deployment.

5.The RADIUS server returns the list of internal hosts and subnets to the system as part of the RADIUS Access-Accept message.

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 and 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:

To know the maximum split tunnel networks supported per tunnel, refer the KB article KB16725 add in 22.5R2.1 Release.

•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.

•A user attribute, for example <userAttr.Framed-Route>, to send to the back-end authentication server.

•You can specify both IP address/netmask combinations and user attributes in the Resources section.

•Please note the following:

•If a user attribute is configured in the resource list, it is dynamically resolved from the user session data.

•Invalid entries (including "*") are ignored.

•If a configured user attribute is not resolved at runtime for the resource lists, the device acts as if split tunneling is disabled.

•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.

•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 - 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 - To 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 - Network IP address/netmask combinations specified in the Resources list pass through the VPN tunnel.

•Exclude access - 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') - 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.