Defining VPN Tunneling Role Settings

Use role-level settings to specify split-tunneling, auto-launch, auto-uninstall, Graphical Identification and Authentication (GINA) options.

To specify VPN tunneling split-tunneling, auto-launch, auto-uninstall, and GINA installation options:

1.In the admin console, choose Users > User Roles > Role Name > VPN Tunneling.

2.Under Options, select one of the following Split Tunneling options:

•Enable - This option activates split-tunneling and adds (or modifies) routes for specific subnets to go to the tunnel, allowing access to the protected subnets. The subnets are specified in the Users > Resource Policies > VPN Tunneling > Split-tunneling Networks window. In the case of subnet overlap (for example, the specified split-tunnel subnet conflicts with an existing endpoint route), the Route Precedence option (described below) is used.

•Disable - All network traffic from the client goes through the VPN tunnel, allowing access to the protected network. When the session is established, predefined local subnet and host-to-host routes that might cause split-tunneling behavior are removed, and all network traffic from the client goes through the VPN tunnel. With split tunneling disabled, users cannot access local LAN resources during an active VPN session.

3.Under VPN client options, select:

•Route precedence - This option defines how the directly-connected subnet routes and the indirectly-connected subnet routes are modified. The exact effect depends on whether split-tunneling is enabled.

•Tunnel Routes - The route table associated with the Ivanti virtual adapter take precedence. Ivanti Secure Access Client overwrites the physical interface routes if there is conflict between the Ivanti virtual adapter and the physical adapters. Ivanti Secure Access Client restores the original routes when the connection is ended.

•Tunnel Routes with local subnet access (on Windows and Mac OS X only) - Network traffic addressed to the networks defined in the split tunnel resource policies goes through the VPN tunnel. Network traffic that is addressed to the directly-connected (local) subnet goes to the local subnet. The default route is set to the local subnet, so all other network traffic is subject to the original endpoint routing table.

•Endpoint Routes - The route table associated with the endpoint's physical adapter take precedence.

Setting route precedence to Endpoint Routes allows users to access the local subnet regardless of whether split tunneling is enabled or disabled.

•Route Monitor - Specify whether you want route monitoring enabled.

•Yes - VPN tunneling ends the connection only if the route change affects the VPN tunnel traffic. For example, if the route metric is changed higher, it should not disconnect VPN tunneling.

•No - Route tables are allowed to change on the client endpoint.

•Traffic Enforcement - When Traffic Enforcement is enabled, Ivanti Secure Access Client creates rules on the endpoint's firewall (Mac and Win) that ensure that all traffic conforms to the split tunneling configuration. For example, a local program might bypass the routing tables and bind traffic to the physical interface instead of allowing it to go through the Ivanti virtual interface. If you enable traffic enforcement, you ensure that all traffic is bound by the split tunneling configuration.

•IPv4 - All IPv4 traffic should go through tunnel according to routes.

•IPv6 - All IPv6 traffic should go through tunnel according to routes.

•Enable TOS Bits Copy - Select this option to control the client behavior in networks that employ quality of service (QoS) protocols. When you enable this check box, the Ivanti Secure Access Client copies IP Type of Service (TOS) bits from the inner IP header to outer the IP Header. Note that enabling this option might require a reboot of the client endpoint when the client software is installed for the first time on Windows endpoints. Ivanti Secure Access Client support TOS bit copy only for IPsec transport and not for SSL transport.

•Multitask - Select this option if you want VPN tunneling to operate in multicast mode.

•Auto-launch - Select this option to activate VPN tunneling automatically when the endpoint is started.

4.Under Options for VPN client on Windows, select:

•Launch client during Windows Interactive User Logon - When this option is enabled, the Ivanti Secure Access Client starts when the user logs into Windows. Note that this setting is not the same as the Ivanti connection settings that control machine authentication and credential provider authentication. Choose one of the following options:

Require client to start when logging into Windows

Allow user to decide whether to start client when logging into Windows

5.For Session Scripts, specify the following:

•Windows: Session start script - Specify a script (.bat, .cmd, or .exe) to run for users assigned to the role after Ivanti connects with Ivanti Connect Secure. For example, you can specify a script that maps network drives on an endpoint to shares on protected resources.

•Windows: Session end script - Specify a script (.bat, .cmd, or .exe) to run for users assigned to the role after Ivanti disconnects from Ivanti Connect Secure. For example, you can specify a script that disconnects mapped network drives. If there is no start script defined, or the start script has not been run, the end script does not run.

•Select the Skip if Windows Interactive User Logon Enabled option to bypass the specified Windows session start script.

If the client signs in to their Windows Domain via the GINA/Credential Provider automatic sign-in function, a script is executed by the Windows client. In this case, the sign-in script may be identical to the specified VPN Tunneling start script. You can use this option, therefore, as a way to avoid executing the same script twice.

Windows only supports scripts with the .bat or .cmd extension (referring to batch files, not the .cmd applications within MSDOS). To run a .vbs script, the user must have a batch file to call the .vbs script. Similarly, to run an .exe application (like C:\WINDOWS\system32\mstsc.exe), the user must have a batch file to call the .exe application.

•Options for VPN client on Mac apply only to Ivanti on Apple OS X endpoints:

•Mac: Session start script - Specify a script (.bat, .cmd, or .exe) to run for users assigned to the role after Ivanti connects with Ivanti Connect Secure. For example, you can specify a script that maps network drives on an endpoint to shares on protected resources.

•Mac: Session end script - Specify a script (.bat, .cmd, or .exe) to run for users assigned to the role after Ivanti disconnects from Ivanti Connect Secure. For example, you can specify a script that disconnects mapped network drives. If there is no start script defined, or the start script has not been run, the end script does not run.

•Linux: Session start script - Specify a script (.bat, .cmd, or .exe) to run for users assigned to the role after Ivanti connects with Ivanti Connect Secure. For example, you can specify a script that maps network drives on an endpoint to shares on protected resources.

•Linux: Session end script - Specify a script (.bat, .cmd, or .exe) to run for users assigned to the role after Ivanti disconnects from Ivanti Connect Secure. For example, you can specify a script that disconnects mapped network drives. If there is no start script defined, or the start script has not been run, the end script does not run.

When VPN tunneling launches, start and end scripts are copied to the client and, upon session termination, are removed from the client. Scripts can be accessed locally or remotely via file share or other permanently-available local network resource. Macintosh clients only support running start and end script located on the local machine.

The client should be a member of the same domain as the remote server to allow VPN tunneling to copy start and end scripts. If the client credentials are unknown to the server, the script copy fails, and VPN tunneling does not prompt the user to enter username and password.

The client makes a copy of the end script after the tunnel has been set up and stores the script in a temporary directory to ensure that, if the network connection were to fail, the end script can still be used to terminate the VPN tunnel session.

6.Click Save Changes.