VPN Monitoring Methods

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.

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

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).

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

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.