About VPN Tunneling

The VPN tunneling access option (formerly called Network Connect) provides a VPN user experience, serving as an additional remote access mechanism to corporate resources using Connect Secure. This feature supports all Internet-access modes, including dial-up, broadband, and LAN scenarios, from the client machine and works through client-side proxies and firewalls that allow SSL traffic.

When a user launches VPN tunneling, the system transmits all traffic to and from the client over the secure VPN tunnel. The only exception is for traffic initiated by other system-enabled features, such as Web browsing, file browsing, and telnet/SSH. If you do not want to enable other system features for certain users, create a user role for which only the VPN tunneling option is enabled and make sure that users mapped to this role are not also mapped to other roles that enable other system features.

With VPN tunneling, the client’s machine effectively becomes a node on the remote (corporate) LAN and becomes invisible on the user’s local LAN; the system serves as the Domain Name Service (DNS) gateway for the client and knows nothing about the user’s local LAN. Users may define static routes on their PCs, however, to continue to access the local LAN while simultaneously connecting to the remote LAN. Since PC traffic goes through the VPN tunnel to your internal corporate resources, make sure that other hosts within a user’s local network cannot connect to the PC through the VPN tunnel.

In the event of broken network connectivity, only the Windows and Macintosh versions of VPN tunneling try (indefinitely) to reconnect.

You can ensure that other hosts in a remote user’s LAN cannot reach internal corporate resources by denying the user access to the local subnet (configured on the Users > User Roles > Select Role > VPN Tunneling tab). If you do not allow access to a local subnet, then the system terminates VPN tunneling sessions initiated by clients on which static routes are defined. You may also require clients to run endpoint security solutions, such as a personal firewall, before launching a network-level remote access session. Host Checker, which performs endpoint security checks on hosts that connect to a device, can verify that clients use endpoint security software.

Note: A Hosts file entry is added by VPN tunneling to support the following case:

  • If, when VPN Tunneling connects, split tunneling is disabled and the original externally resolved hostname (the hostname the user initially connected to prior to the VPN tunnel launch) resolves to another IP address against the internal DNS, the browser will redirect to a “Server not found” page, because no route is defined within the client system.
  • At a graceful termination (sign-out or timeout) of the VPN tunnel client connection, the Hosts file is restored. If the Hosts file was not restored in a prior case due to an ungraceful termination, the Hosts file will be restored the next time the user launches VPN tunneling.

For VPN tunneling to communicate, the following ports must be open:

The VPN tunneling option provides secure, SSL-based network-level remote access to all enterprise application resources using the device over port 443. Port 4242 is used for IPC communication between the VPN tunneling service and the VPN tunnel executable on the client PC. Typically endpoint products do not block this type of IPC communication. However, if you have an endpoint product that does block this communication, you must allow it for VPN tunneling to work properly.

Note: If you enable the multiple sessions per user feature, VPN tunnel clients may not be assigned the same IP address. For example, VPN tunnel client may be assigned a different VIP address each time they connect to a device when the system is obtaining the DHCP addresses from a DHCP server.

Related Topics