Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Monitoring IPsec VPN Sessions

Understanding VPN Monitoring

VPN monitoring uses ICMP echo requests (or pings) to determine if a VPN tunnel is up. When VPN monitoring is enabled, the security device sends pings through the VPN tunnel to the peer gateway or to a specified destination at the other end of the tunnel. Pings are sent by default at intervals of 10 seconds for up to 10 consecutive times. If no reply is received after 10 consecutive pings, the VPN is considered to be down and the IPsec security association (SA) is cleared.

VPN monitoring is enabled for a specified VPN by configuring the vpn-monitor option at the [edit security ipsec vpn vpn-name] hierarchy level. The peer gateway’s IP address is the default destination; however, you can specify a different destination IP address (such as a server) at the other end of the tunnel. The local tunnel endpoint is the default source interface, but you can specify a different interface name.

VPN monitoring of an externally connected device (such as a PC) is not supported on SRX5400, SRX5600, and SRX5800 devices. The destination for VPN monitoring must be a local interface on the SRX5400, SRX5600, or SRX5800 device.

The VPN monitoring optimized option sends pings only when there is outgoing traffic and no incoming traffic through the VPN tunnel. If there is incoming traffic through the VPN tunnel, the security device considers the tunnel to be active and does not send pings to the peer. Configuring the optimized option can save resources on the security device because pings are only sent when peer liveliness needs to be determined. Sending pings can also activate costly backup links that would otherwise not be used.

You can configure the interval at which pings are sent and the number of consecutive pings that are sent without a reply before the VPN is considered to be down. These are configured with the interval and threshold options, respectively, at the [edit security ipsec vpn-monitor-options] hierarchy level.

VPN monitoring can cause tunnel flapping in some VPN environments if ping packets are not accepted by the peer based on the packet’s source or destination IP address.

Understanding IPsec Datapath Verification

Overview

By default, the state of the secure tunnel (st0) interfaces configured in point-to-point mode in route-based VPNs is based on the state of the VPN tunnel. Soon after the IPsec SA is established, routes associated with the st0 interface are installed in the Junos OS forwarding table. In certain network topologies, such as where a transit firewall is located between the VPN tunnel endpoints, IPsec data traffic that uses active routes for an established VPN tunnel on the st0 interface may be blocked by the transit firewall. This can result in traffic loss.

When you enable the IPsec datapath verification, the st0 interface is not brought up and activated until the datapath is verified. The verification is configured with the set security ipsec vpn vpn-name vpn-monitor verify-path statement for route-based, site-to-site, and dynamic endpoint VPN tunnels.

If there is a NAT device in front of the peer tunnel endpoint, the IP address of the peer tunnel endpoint is translated to the IP address of the NAT device. For the VPN monitor ICMP request to reach the peer tunnel endpoint, you need to explicitly specify the original, untranslated IP address of the peer tunnel endpoint behind the NAT device. This is configured with the set security ipsec vpn vpn-name vpn-monitor verify-path destination-ip configuration.

Starting in Junos OS Release 15.1X49-D120, you can configure the size of the packet that is used to verify an IPsec datapath before the st0 interface is brought up. Use the set security ipsec vpn vpn-name vpn-monitor verify-path packet-size configuration. The configurable packet size ranges from 64 to 1350 bytes; the default is 64 bytes.

Caveats

The source interface and destination IP addresses that can be configured for VPN monitor operation have no effect on the IPsec datapath verification. The source for the ICMP requests in the IPsec datapath verification is the local tunnel endpoint.

When you enable IPsec datapath verification, VPN monitoring is automatically activated and used after the st0 interface is brought up. We recommend that you configure the VPN monitor optimized option with the set security ipsec vpn vpn-name vpn-monitor optimized command whenever you enable IPsec datapath verification.

If a chassis cluster failover occurs during the IPsec datapath verification, the new active node starts the verification again. The st0 interface is not activated until the verification succeeds.

No IPsec datapath verification is performed for IPsec SA rekeys, because the st0 interface state does not change for rekeys.

IPsec datapath verification is not supported on st0 interfaces configured in point-to-multipoint mode that are used with AutoVPN, Auto Discovery VPN, and multiple traffic selectors. VPN monitoring and IPsec datapath verification do not support IPv6 addresses, so IPsec datapath verification cannot be used with IPv6 tunnels.

Understanding Global SPI and VPN Monitoring Features

You can monitor and maintain the efficient operation of your VPN using the following global VPN features:

  • SPI—Peers in a security association (SA) can become unsynchronized when one of the peers fails. For example, if one of the peers reboots, it might send an incorrect security parameter index (SPI). You can enable the device to detect such an event and resynchronize the peers by configuring the bad SPI response feature.

  • VPN monitoring—You can use the global VPN monitoring feature to periodically send Internet Control Message Protocol (ICMP) requests to the peer to determine if the peer is reachable.

Understanding VPN Monitoring and DPD

VPN monitoring and dead peer detection (DPD) are features available on SRX Series devices to verify the availability of VPN peer devices. This section compares the operation and configuration of these features.

The SRX Series device responds to DPD messages sent by VPN peers even if DPD is not configured on the device. You can configure the SRX Series device to initiate DPD messages to VPN peers. You can also configure DPD and VPN monitoring to operate simultaneously on the same SRX Series device, although the number of peers that can be monitored with either method is reduced.

VPN monitoring is a Junos OS mechanism that monitors only Phase 2 security associations (SAs). VPN monitoring is enabled on a per-VPN basis with the vpn-monitor statement at the [edit security ipsec vpn vpn-name] hierarchy level. The destination IP and source interface must be specified. The optimized option enables the device to use traffic patterns as evidence of peer liveliness; ICMP requests are suppressed.

VPN monitoring options are configured with the vpn-monitor-options statement at the [edit security ipsec] hierarchy level. These options apply to all VPNs for which VPN monitoring is enabled. Options you can configure include the interval at which ICMP requests are sent to the peer (the default is 10 seconds) and the number of consecutive ICMP requests sent without receiving a response before the peer is considered unreachable (the default is 10 consecutive requests).

DPD is an implementation of RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers. It operates at the IKE level and monitors the peer based on both IKE and IPsec traffic activity.

DPD is configured on an individual IKE gateway with the dead-peer-detection statement at the [edit security ike gateway gateway-name] hierarchy level. You can configure DPD modes of operation. The default (optimized) mode sends DPD messages to the peer if there is no incoming IKE or IPsec traffic within a configured interval after the local device sends outgoing packets to the peer. Other configurable options include the interval at which DPD messages are sent to the peer (the default is 10 seconds) and the number of consecutive DPD messages sent without receiving a response before the peer is considered unavailable (the default is five consecutive requests).

Understanding Dead Peer Detection

Dead peer detection (DPD) is a method that network devices use to verify the current existence and availability of other peer devices.

You can use DPD as an alternative to VPN monitoring. VPN monitoring applies to an individual IPsec VPN, while DPD is configured only in an individual IKE gateway context.

A device performs DPD verification by sending encrypted IKE Phase 1 notification payloads (R-U-THERE messages) to a peer and waiting for DPD acknowledgments (R-U-THERE-ACK messages) from the peer. The device sends an R-U-THERE message only if it has not received any traffic from the peer during a specified DPD interval. If the device receives an R-U-THERE-ACK message from the peer during this interval, it considers the peer alive. If the device receives traffic on the tunnel from the peer, it resets its R-U-THERE message counter for that tunnel, thus starting a new interval. If the device does not receive an R-U-THERE-ACK message during the interval, it considers the peer dead. When the device changes the status of a peer device to be dead, the device removes the Phase 1 security association (SA) and all Phase 2 SAs for that peer.

The following DPD modes are supported on the SRX Series devices:

  • Optimized—R-U-THERE messages are triggered if there is no incoming IKE or IPsec traffic within a configured interval after the device sends outgoing packets to the peer. This is the default mode.

  • Probe idle tunnel—R-U-THERE messages are triggered if there is no incoming or outgoing IKE or IPsec traffic within a configured interval. R-U-THERE messages are sent periodically to the peer until there is traffic activity. This mode helps in early detection of a downed peer and makes the tunnel available for data traffic.

    When multiple traffic selectors are configured for a VPN, multiple tunnels can be established for the same IKE SA. In this scenario, the probe idle tunnel mode triggers R-U-THERE messages to be sent if any tunnel associated with the IKE SA becomes idle, even though there may be traffic in another tunnel for the same IKE SA.

  • Always send—R-U-THERE messages are sent at configured intervals regardless of traffic activity between the peers.

    We recommend that the probe idle tunnel mode be used instead of the always-send mode.

DPD timers are active as soon as the Phase 1 SA is established. The DPD behavior is the same for both IKEv1 and IKEv2 protocols.

You can configure the following DPD parameters:

  • The interval parameter specifies the amount of time (expressed in seconds) the device waits for traffic from its peer before sending an R-U-THERE message. The default interval is 10 seconds. Starting with Junos OS Release 15.1X49-D130, the permissible interval parameter range at which R-U-THERE messages are sent to the peer device is reduced from 10 through 60 seconds to 2 seconds through 60 seconds. The minimum threshold parameter should be 3, when the DPD interval parameter is set less than 10 seconds.

  • The threshold parameter specifies the maximum number of times to send the R-U-THERE message without a response from the peer before considering the peer dead. The default number of transmissions is five times, with a permissible range of 1 to 5 retries.

Note the following considerations before configuring DPD:

  • When a DPD configuration is added to an existing gateway with active tunnels, R-U-THERE messages are started without clearing Phase 1 or Phase 2 SAs.

  • When a DPD configuration is deleted from an existing gateway with active tunnels, R-U-THERE messages are stopped for the tunnels. IKE and IPsec SAs are not affected.

  • Modifying any DPD configuration option such as the mode, interval, or threshold values updates the DPD operation without clearing Phase 1 or Phase 2 SAs.

  • If the IKE gateway is configured with DPD and VPN monitoring but the option to establish tunnels immediately is not configured, DPD does not initiate Phase 1 negotiation. When DPD is configured, the establish tunnels immediately option must also be configured at the same time to tear down the st0 interface when there are no phase 1 and phase 2 SAs available.

  • If the IKE gateway is configured with multiple peer IP addresses and DPD but Phase 1 SA fails to be established to the first peer IP address, a Phase 1 SA is attempted with the next peer IP address. DPD is active only after a Phase 1 SA is established.

  • If the IKE gateway is configured with multiple peer IP addresses and DPD but DPD fails with the current peer’s IP address, the Phase 1 and Phase 2 SAs are cleared and a failover to the next peer IP address is triggered.

  • More than one Phase 1 or Phase 2 SA can exist with the same peer because of simultaneous negotiations. In this case, R-U-THERE messages are sent on all Phase 1 SAs. Failure to receive DPD responses for the configured number of consecutive times clears the Phase 1 SA and the associated Phase 2 SA (for IKEv2 only).

Understanding Tunnel Events

When there is a network problem related to a VPN, after the tunnel comes up only the tunnel status is tracked. Many issues can occur before the tunnel comes up. Hence, instead of tracking only the tunnel status, tunnel down issues, or negotiation failures, successful events such as successful IPsec SA negotiations, IPsec rekey, and IKE SA rekeys are now tracked. These events are called tunnel events.

For Phase 1 and Phase 2, negotiation events for a given tunnel are tracked along with the events that occur in external daemons like AUTHD or PKID. When a tunnel event occurs multiple times, only one entry is maintained with the updated time and the number of times that event occurred.

Overall, 16 events are tracked: eight events for Phase 1 and eight events for Phase 2. Some events can reoccur and fill up the event memory, resulting in important events being removed. To avoid overwriting, an event is not stored unless a tunnel is down.

The following special events fall into this category:

  • Lifetime in kilobytes expired for IPsec SA

  • Hard lifetime of IPsec SA expired

  • IPsec SA delete payload received from peer, corresponding IPsec SAs cleared

  • Cleared unused redundant backup IPsec SA pairs

  • IPsec SAs cleared as corresponding IKE SA deleted

AutoVPN tunnels are created and removed dynamically and consequently tunnel events corresponding to these tunnels are short lived. Sometimes these tunnel events cannot be associated with any tunnel so system logging is used for debugging instead.

Release History Table
Release
Description
15.1X49-D130
Starting with Junos OS Release 15.1X49-D130, the permissible interval parameter range at which R-U-THERE messages are sent to the peer device is reduced from 10 through 60 seconds to 2 seconds through 60 seconds. The minimum threshold parameter should be 3, when the DPD interval parameter is set less than 10 seconds.
15.1X49-D120
Starting in Junos OS Release 15.1X49-D120, you can configure the size of the packet that is used to verify an IPsec datapath before the st0 interface is brought up.