Access Methods
The Pulse Secure Desktop Client supports the following kinds of connections to Pulse Secure gateways:
•Layer 3 VPN connections to Pulse Connect Secure
•Layer 2 (802.1x) and Layer 3 connections to Pulse Policy Secure
•Per-application VPN tunneling to Pulse Connect Secure (Windows Secure Access Manager)
There are a vast number of possible combinations of connections and configurations. For example, both Layer 2 (wired and wireless) and Layer 3 connections can be configured either with or without enforcement (Host Checker enforcement of system health and policy compliance). Although an endpoint can have only one active VPN connection to Pulse Connect Secure, an endpoint can have multiple simultaneous Pulse Policy Secure connections with or without a VPN connection. Also, Pulse Policy Secure IPsec enforcement in Pulse Connect Secure (TLS) tunnels is supported.
The following table lists the configurations that are qualified and compatible. Any combination not mentioned in the table is not supported.
|
Access Method Configuration |
Description |
Level of Support |
|
Layer 3 IPsec tunnel inside VPN outer tunnel |
Outer tunnel: TLS or ESP VPN tunnel to Pulse Connect Secure gateway Inner tunnel: Layer 3 IPsec tunnel authenticated through Pulse Policy Secure to ScreenOS or SRX firewall |
Qualified |
|
Layer 2 Pulse Policy Secure + |
One Pulse Policy Secure Layer 2 connection running in parallel to multiple Pulse Policy Secure Layer 3 connections |
Qualified |
The following table lists the supported nested tunnel (tunnel-in-tunnel) configurations. The configurations are for a Pulse Connect Secure v9.1 outer tunnel, a Pulse Policy Secure v9.1 inner tunnel, and the Pulse Secure Desktop Client v9.1.
|
Pulse Connect Secure (Outer Tunnel Config) |
Pulse Policy Secure (Inner Tunnel Support) |
|||||||
|
Split-Tunneling Mode |
Route Precedence |
Route Monitor |
Traffic Enforcement |
IPsec |
IPsec (without VA) |
Dynamic IPsec |
Source IP |
Dynamic Source IP |
|
Disabled |
Tunnel Routes1 |
Disabled |
Disabled |
Supported |
Supported |
Supported |
Supported |
Supported |
|
Disabled |
Tunnel Routes1 |
Disabled |
IPv4 Disabled and IPv6 Enabled |
Supported |
Supported |
Supported |
Supported |
Supported |
|
Disabled |
Tunnel Routes1 |
Disabled |
IPv4 Enabled and IPv6 Disabled |
Not Supported |
Supported |
Supported |
Supported |
Supported |
|
Disabled |
Tunnel Routes |
Enabled |
Enabled or Disabled |
Not Supported |
Supported |
Supported |
Supported |
Supported |
|
Enabled |
Tunnel Routes1 |
Disabled |
Enabled or Disabled |
Supported2 |
Supported3 |
Supported |
Supported |
Supported |
|
Enabled |
Tunnel Routes1 |
Enabled |
Enabled or Disabled |
Supported2 |
Supported3 |
Supported |
Supported |
Supported |
|
Enabled or Disabled |
Endpoint routes |
Enabled or Disabled |
Enabled or Disabled |
Supported2 |
Supported3 |
Supported |
Supported |
Supported |
1.Tunnel Routes and Tunnel Routes with Local Subnet Access behave the same way.
2.Pulse Policy Secure IP address, IE IP address, and Pulse Policy Secure VA pool IP addresses should be added to the Pulse split-tunnelling network policy.
3.Pulse Policy Secure IP address, IE IP address, and protected resources should be added to a Pulse split-tunnelling network policy, and Pulse Connect Secure should have a route to the Pulse Policy Secure protected resource.
Pulse WSAM does not inter-operate with Pulse Policy Secure.