Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

VPN Monitoring Methods

SUMMARY Read this topic to understand multiple ways in which you can monitor the VPN tunnel in an SRX Series Firewall.

We would expect the VPN tunnel to function optimally all the time. But that’s hardly the case in a real world scenario. We know that the VPN tunnel can be down because of multiple reasons.

Junos OS offers following methods to monitor a VPN:

  • IPsec datapath verification using Internet Control Message Protocol (ICMP) to check the datapath.

  • Dead Peer Detection (DPD) protocol configuration to check the liveness of the IKE peer.

  • VPN tunnel monitoring configuration to check the liveness of IPsec security association.

Additionally, you can use the following global VPN features for monitoring:

  • VPN peers in a security association (SA) can become unsynchronized when one of the peers doesn't respond. 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. For more information about the respond-bad-spi max-responses option, see ike (Security).

  • You can periodically send Internet Control Message Protocol (ICMP) requests to the peer to determine whether the peer is reachable. For more information about the vpn-monitor-options option, see ipsec (Security).

You can choose to configure any of the methods explained in this topic to monitor your VPN.

IPsec Datapath Verification

IPsec datapath verification is a process of validating the datapath between the tunnel endpoints to check that the path is clear and not blocked by any transit firewall.

Why Do You Need IPsec Datapath Verification?

The state of the secure tunnel (st0) interface in point-to-point mode for route-based VPNs is typically based on the state of the VPN tunnel. After the device establishes the IPsec security association, the Junos OS adds routes associated with the st0 interface to the forwarding table. If your network has a transit firewall between the VPN tunnel endpoints, the firewall might block IPsec data traffic that uses active routes on the st0 interface. As a result, you might encounter traffic loss.

To avoid such traffic loss, you must enable IPsec datapath verification. When you enable this feature, the Junos OS device doesn’t bring up the st0 interface until it verifies the datapath. You can configure the datapath verification with the following options:

  • You can configure with the statement [set security ipsec vpn vpn-name vpn-monitor verify-path] for route-based and site-to-site VPN tunnels.

  • If there is a NAT device in front of the peer tunnel endpoint, the firewall translates the IP address of the peer tunnel endpoint 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. You can configure this with the [set security ipsec vpn vpn-name vpn-monitor verify-path destination-ip] configuration statement.

  • 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 statement. The configurable packet size ranges from 64 to 1350 bytes; the default is 64 bytes.

Consider the following points when using IPsec datapath verification:

  • The source interface and destination IP addresses that you configure for VPN monitoring 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, Junos OS automatically activates VPN monitoring only after the st0 interface is up. We recommend that you configure the vpn-monitor optimized option at the [edit security ipsec vpn vpn-name] hierarchy level when you enable IPsec datapath verification.

  • If a chassis cluster failover occurs during the IPsec datapath verification, the new active node starts the verification again. Junos OS doesn't active the st0 interface until the verification succeeds.

  • For IPsec security association rekeys, Junos OS doesn't perform IPsec datapath verification, because the st0 interface state does not change for rekeys.

  • Junos OS does not support IPsec datapath verification on st0 interfaces in a point-to-multipoint mode that are used with AutoVPN, Auto Discovery VPN (ADVPN), and multiple traffic selectors.

  • VPN monitoring and IPsec datapath verification do not support IPv6 addresses. Therefore, you cannot use IPsec datapath verification with IPv6 tunnels.

How Does IPsec Datapath Verification Work?

When you configure IPsec datapath verification, the following events occur:

  1. After the device establishes the VPN tunnel, it sends an ICMP request to the peer tunnel endpoint to verify the IPsec datapath.
 The peer tunnel endpoint must be reachable by VPN monitor ICMP requests and must be able to respond to the ICMP request. While the datapath verification is in progress, the VPN Monitoring field in the show security ipsec security-association detail command output displays the letter V.

  2. Junos OS activates st0 interface only when it receives a response from the peer. The show interface st0.x command output shows the st0 interface status during and after the datapath verification: Link-Layer-Down before the verification finishes and Up after the verification finishes successfully.

  3. If the peer doesn't send an ICMP response, the device sends another ICMP request at the configured VPN monitor interval until it reaches the configured VPN monitor threshold value.
 Note that the default VPN monitor interval is 10 seconds and the default VPN monitor threshold value is 10 times. If the verification does not succeed, the KMD_VPN_DOWN_ALARM_USER system log entry indicates the reason as a VPN monitoring verify-path error. The device logs an error under tunnel events in the show security ipsec security-association detail command output. The show security ipsec tunnel-events-statistics command displays the number of times the error occurred.
 You can configure the VPN monitor interval and the VPN monitor threshold value using the vpn-monitor-options configuration option at the [edit security ipsec] hierarchy level.

  4. If the peer doesn't send an ICMP response even after it reaches the VPN monitor threshold value, then Junos OS brings down the VPN tunnel and renegotiates the VPN tunnel.

Dead Peer Detection

Dead Peer Detection (DPD) is a standards-based protocol that uses the network traffic to detect the liveness of an IKE peer in an IPsec connection.

How Does DPD Work?

During IPsec tunnel creation, VPN peers negotiate to decide whether to use the dead peer detection (DPD) method or not. If the peers agree to use the DPD method, when there is no active traffic, the DPD protocol sends periodic messages to the peer and waits for a response. If the peer does not respond to the messages, the DPD protocol assumes that the peer is no longer available. The behavior of DPD is the same for both IKEv1 and IKEv2 protocols. DPD timers are active as soon as the IKE establishes Phase 1 Security Association (SA).

An SRX Series Firewall uses the DPD protocol to detect the liveness in an IPsec VPN connection.

Figure 1: Message Exchange in DPD Protocol Message Exchange in DPD Protocol

Figure 1 shows the exchange of DPD messages between the IKE peers in an IPsec VPN tunnel. The following events occur when the firewall device performs DPD:

  1. The firewall SRX-A waits until the specified DPD interval to check whether it has received any traffic from the peer, SRX-B.

  2. If SRX-A does not receive any traffic from SRX-B during the specified DPD interval, it sends an encrypted IKE Phase 1 notification payload—an R-U-THERE message—to SRX-B.

  3. SRX-A waits for the DPD acknowledgment—an R-U-THERE-ACK message—from SRX-B.

    1. If SRX-A receives an R-U-THERE-ACK message from SRX-B during this interval, it considers the peer alive. Then SRX-A resets its R-U-THERE message counter for that tunnel, and starts a new interval.

    2. If SRX-A does not receive an R-U-THERE-ACK message during the interval, it considers the peer, SRX-B, down. SRX-A then removes the Phase 1 security association and all Phase 2 security associations for that peer.

Configurable DPD Parameters

Here's a list of DPD parameters you'll need to configure:

  • Mode—Based on the traffic activity, you can configure DPD in one of the following modes:

    • Optimized—In the optimized mode, when the initiating device sends outgoing packets to the peer, if there is no incoming IKE or IPsec traffic from the peer within the configured interval, the initiating device triggers R-U-THERE messages. DPD operates in this default mode unless you configure another mode.

    • Probe idle tunnel—In the probe idle tunnel mode, the device triggers R-U-THERE messages if there is no incoming or outgoing IKE or IPsec traffic within a configured interval. The device sends R-U-THERE messages periodically to the peer until there is traffic activity. This mode helps in early detection of a peer that is down, ensuring tunnel availability during the active traffic flow.


      Note:

      In this scenario, when you configure probe idle tunnel mode, the device triggers R-U-THERE messages if a tunnel becomes idle regardless of the traffic in another tunnel for the same IKE security association.

    • Always-send—In the always-send mode, the device sends R-U-THERE messages at a configured interval regardless of traffic activity between the peers.
 We recommend that you use probe idle tunnel mode instead of always-send mode.

  • Interval—Use the interval parameter to specify the amount of time (in seconds) that 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, we've reduced the permissible interval parameter range at which R-U-THERE messages are sent to the peer device from 10 seconds through 60 seconds to 2 seconds through 60 seconds. We recommend that you set the minimum threshold parameter to 3, when the DPD interval parameter is set to less than 10 seconds.

  • Threshold—Use the threshold parameter to specify the maximum number of times the device sends the R-U-THERE message without receiving a response from the peer before it considers the peer down. The default number of transmissions is five, with a permissible range of 1 through 5 retries.

Note the following considerations before configuring DPD:

  • After you add the DPD configuration to an existing gateway with active tunnels, the device starts triggering R-U-THERE messages without clearing Phase 1 or Phase 2 security associations.

  • When you delete the DPD configuration from an existing gateway with active tunnels, the device stops triggering R-U-THERE messages for the tunnels. But this doesn't affect IKE and IPsec security associations.

  • When you modify DPD configuration parameters such as the mode, interval, or threshold values, IKE updates the DPD operation without clearing Phase 1 or Phase 2 security associations.

  • If you configure the IKE gateway with DPD and VPN monitoring without specifying the option to establish tunnels immediately, IKE does not initiate Phase 1 negotiation. When you configure DPD, you must also configure the establish-tunnels immediately option at the [edit security ipsec vpn vpn-name] hierarchy level to tear down the st0 interface when no phase 1 and phase 2 security associations are available. See vpn (Security) for establish-tunnels option .

  • If you configure the IKE gateway with multiple peer IP addresses and DPD, but fail to establish Phase 1 SA with the first peer IP address, IKE attempts to establish with the next peer IP address. DPD is active only after the IKE establishes Phase 1 security association. See dead-peer-detection.

  • If you configure the IKE gateway with multiple peer IP addresses and DPD, but the connection fails with the current peer’s IP address, IKE clears Phase 1 and Phase 2 security associations and DPD does a failover to the next peer IP address. See gateway (Security IKE).

  • More than one Phase 1 or Phase 2 SA can exist with the same peer because of simultaneous negotiations. In this case, DPD sends R-U-THERE messages to all Phase 1 security associations. If the gateway fails to receive DPD responses for the configured number of consecutive times, it clears the Phase 1 security association and the associated Phase 2 security association (for IKEv2 only).

Note:

For more details about DPD implementation, see RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers.

If the IKE peer is alive, does it mean that the underlying VPN is up?

Tip:

Think whether DPD ensures IPsec SA liveness. See VPN Tunnel Monitoring .

VPN Tunnel Monitoring

VPN monitoring is a Junos OS proprietary feature of monitoring a VPN tunnel.

While the Dead Peer Detection (DPD) protocol checks the liveness of an IKE peer, it does not guarantee the liveness of an underlying VPN. We've no standards-based method to check whether the underlying VPN is up. VPN monitoring is a Junos OS proprietary mechanism of checking the liveness of an IPsec security association.

How Does VPN Tunnel Monitoring Work?

VPN monitoring uses Internet Control Message Protocol (ICMP) echo requests (or pings) and signature data, such as tunnel ID, in the ICMP packet to determine whether the VPN tunnel is up.

When you enable VPN monitoring, the device sends ICMP echo requests through the VPN tunnel to the peer gateway or to a specified destination at the other end of the tunnel. The device sends the requests by default at intervals of 10 seconds for up to 10 consecutive times. If the device doesn't receive any reply after 10 consecutive pings, it considers the VPN down and clears the IPsec security association.

Use the following operating modes to monitor VPN tunnels:

  • Always-send mode—In this mode, the device sends a VPN monitoring packet once every configured interval irrespective of the traffic in the tunnel. After you enable VPN monitoring, Junos OS uses always-send mode as the default mode if you don't specify one.

  • Optimized mode—In this mode, the device sends a VPN monitoring packet once every configured interval only if there is outgoing traffic and no incoming traffic through the tunnel during the interval. If there is incoming traffic through the VPN tunnel, the device considers the tunnel to be active and stops sending pings to the peer. You can use optimized mode to save resources on the device because in this mode the device sends pings only when it needs to determine peer liveness. Sending pings can also activate costly backup links that would otherwise not be used.

    The device operates in the default always-send mode if you don't configure optimized mode explicitly.

Configure Dead Peer Detection

Before you begin, ensure that you have the IKE gateway configured. See gateway (Security IKE) for more details.

In this topic, you'll learn how to configure the Dead Peer Detection (DPD) protocol and its parameters on Juniper Networks® SRX Series Firewalls. To enable the device with DPD:

  1. Specify the DPD mode probe-idle-tunnel at the [edit security ike gateway gateway-name] hierarchy level. See Configurable DPD Parameters and dead-peer-detection for more details.
    Here we use vpngw1 as the gateway-name.
  2. Configure the interval at the [edit security ike gateway gateway-name] hierarchy level. See Configurable DPD Parameters and dead-peer-detection for more details.
    Here we set an interval of 40 seconds.
  3. Specify the threshold at the [edit security ike gateway gateway-name] hierarchy level. See Configurable DPD Parameters and dead-peer-detection for more details.
    Here we set a threshold of 3, which means the device will ping the peer 3 times before it considers the peer down.
Note:

With the firewall running the iked process for the IPsec VPN service, you can use DPD with multiple peer addresses per gateway. See gateway (Security IKE) for more details.

Configure VPN Tunnel Monitoring

Before you begin, you must have an existing VPN tunnel.

In this topic, you'll learn how to enable VPN tunnel monitoring, and set the interval and threshold parameters for the ping packets used for VPN monitoring on Juniper Networks® SRX Series Firewalls.

  1. Enable VPN monitoring for a specific VPN tunnel using the vpn-monitor option at the [edit security ipsec vpn vpn-name] hierarchy level. See vpn-monitor.
    Here we use vpn1 as the vpn-name.
  2. Configure VPN monitoring mode as optimized.
  3. Specify the destination IP address. The peer gateway’s IP address is the default destination; however, you can specify a different destination IP address (such as that of a server) that is at the other end of the tunnel.
  4. Specify the source-interface address. The local tunnel endpoint is the default source interface, but you can specify a different interface name.
  5. Configure the interval at which the device sends the pings and the number of consecutive pings that it sends with the interval and threshold options, respectively, at the [edit security ipsec vpn-monitor-options] hierarchy level. If you don't configure these options, the device sends pings at the default interval of 10 seconds up to 10 consecutive times. If the device doesn't receive a reply, it considers the VPN down. The device then clears the IPsec security association. See ipsec (Security).
Note:

The SRX5400, SRX5600, and SRX5800 Firewalls do not support VPN monitoring of an externally connected device (such as a PC). On these devices, the destination for VPN monitoring must be a local interface.

CAUTION:

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

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

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.