Reset Search
 

 

Article

KB26667 - Encapsulating Security Payload (ESP) packet flow with Network Connect or Pulse client

« Go Back

Information

 
Last Modified Date9/29/2015 5:59 PM
Synopsis
This article provides information on the workflow for Encapsulating Security Payload (ESP) packet flow, keep-alive with idle timeout, and ESP to SSL failover behavior with Network Connect or Pulse client.

 

Problem or Goal

Detail the workflow for Encapsulating Security Payload (ESP) packet flow, keep-alive with idle timeout, and ESP to SSL failover behavior with Network Connect or Pulse client.

Cause
Solution

ESP packet flow involves the following:

  1. Tunnel creation
  2. ESP keep alive
  3. ESP rekey
  4. ESP packet flow


Tunnel Creation

After a tunnel is created, Network Connect or Pulse client creates a persistent SSL connection (called the control channel on port 443) to the Pulse Connect Secure device. The control channel is used to pass a tunnel setup request and receive the response for the tunnel configuration to/from the Pulse Secure Connect device. If ESP is configured, ESP-specific cipher details are added to the response and sent to the client. When the client receives the response, it will attempt to create a tunnel via ESP mode and send a request to the Pulse Connect Secure device.


ESP keep alive with idle timeout behavior

During tunnel setup

After an ESP tunnel has been created, it will send keep-alive packets to the Pulse Connect Secure device to confirm that the device is accessible through ESP mode. If an ESP response is received, the Pulse or Network Connect client continues operating on the assumption that the ESP tunnel was successfully created. If the ESP tunnel is not successfully created, the client will send a keep-alive packet every one (1) second until the "ESP to SSL fallback time" is exceeded (by default, it is 15 seconds). When this time is exceeded, the Pulse or Network Connect client will fail back to SSL mode.

After the ESP tunnel is functioning

After an ESP tunnel has been successfully created, an idle timeout of one (1) minute is set. When the client receives a data packet or a keep-alive response, this timer is reset back to one (1) minute.

If the one (1) minute idle timer is exceeded, the Pulse or Network Connect client will send a keep-alive packet every one (1) second until either of the following occurs:

  • Client receives a keep-alive response from the Pulse Connect Secure device
  • Client receives a data packet via the tunnel

The idle timeout (60 seconds) + ESP to SSL fallback time (by default, 15 seconds) is the amount of time it takes the client to switch from ESP to SSL mode. In this example, it would take 75 seconds before the client would fail over to SSL mode.

ESP rekey 

By default, key lifetime (under Users > Resource Policies > VPN Tunneling > Connection Profiles) is set to 20 minutes.  When a ESP tunnel is created, a unique ESP SPI id is created by the Pulse Connect Secure device and will be valid for 20 minutes.  At 12 minute mark (3/5 of the key lifetime), the client will attempt to rekey the ESP SPI id and get a new ESP SPI id.  If the rekey is successful, a new SPI id is generated and the 20 minute counter resets.  If the rekey is unsuccessful, the client will wait 60 seconds and attempt the rekey again.  If the client exceeds the key lifetime without a rekey, the ESP tunnel will fallback to SSL mode.


ESP packet flow

Packet flow is defined as follows:

Client > Internet > External (SA device) -- Internal (SA device) > Local LAN or Internal Gateway > Backend server

When an L3 tunnel is created, a virtual adapter interface is created. This interface obtains an NC IP address from the Pulse Connect Secure device. In the example below, split tunneling is disabled (all packets are routed through the virtual adapter). If split tunneling is enabled. the virtual adapter will only capture packets destined for routes configured in the split tunneling policy; all other packets are routed through the client's physical adapter.

  1. An ICMP request packet is formed with the Source IP (NC IP address) and the Destination IP (Backend server IP).
  2. This packet is captured by the virtual adapter interface, and the Network Connect or Pulse application encrypts this packet via ESP with the Source IP (Client's Physical IP address) and the Destination IP (SA External IP or Public IP address of SA device).
  3. The ESP packet travels via the Client's Physical Interface > Internet and reaches the External Interface of the Pulse Connect Secure device.
  4. The Pulse Connect Secure device decrypts the ESP packet and obtains the original packet that was formed in Step 1.
  5. The Pulse Connect Secure device sends the original packet via the Internal interface (Pulse Connect Secure device) from the Source IP (NC IP address) to the Destination IP (Backend server IP).
  6. The original packet is sent to the Internal Gateway or through the local LAN until the packet is delivered to the backend server.
  7. When the backend server receives the ICMP packet, it replies with the Source IP (Backend server) to the Destination IP (NC IP address).
  8. The ICMP reply packet reaches the SA internal interface via the local LAN or Internal Gateway.
  9. The Pulse Connect Secure device encrypts this packet via ESP and sends it from the Source IP (Pulse Connect Secure External IP or Pulse Connect Secure Public IP address) to the Destination IP (Client's Physical IP address).
  10. The client's physical interface receives the ESP packet and the Network Connect or Pulse application decrypts the ESP packet, then sends the original packet to the virtual adapter.
  11. The application receives the ICMP response from the virtual adapter.

For further details on Encapsulating Security Payload (ESP), see RFC2406.

Related Links
Attachment 1 
Created ByData Deployment

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255