Monitoring VPN Traffic
VPN monitoring enables you to determine the reachability of peer devices by sending Internet Control Message Protocol (ICMP) requests to the peers.
Understanding VPN Alarms and Auditing
Configure the following command to enable security event logging during the initial set up of the device. This feature is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, and SRX1500 devices and vSRX instances.
set security log cache
The administrators (audit, cryptographic, IDS and security) cannot modify the security event logging configuration if the above command is configured and each administrator role is configured to have a distinct, unique set of privileges apart from all other administrative roles.
Alarms are triggered by a VPN failure. A VPN alarm is generated when the system monitors any of the following audited events:
Authentication failures—You can configure the device to generate a system alarm when the packet authentication failures reaches a specified number.
Encryption and decryption failures—You can configure the device to generate a system alarm when encryption or decryption failures exceed a specified number.
IKE Phase 1 and IKE Phase 2 failures—Internet Key Exchange (IKE) Phase 1 negotiations are used to establish IKE security associations (SAs). These SAs protect the IKE Phase 2 negotiations. You can configure the device to generate a system alarm when IKE Phase 1 or IKE Phase 2 failures exceed a specified number.
Self-test failures—Self-tests are tests that a device runs upon power on or reboot to verify whether security software is implemented correctly on your device.
Self-tests ensure the correctness of cryptographic algorithms. The Junos-FIPS image performs self-tests automatically upon power-on, and continuously for key-pair generation. In either domestic or FIPS images, self-tests can be configured to be performed according to a defined schedule, upon demand or immediately after key generation.
You can configure the device to generate a system alarm when a self-test failure occurs.
IDP flow policy attacks—An intrusion detection and prevention (IDP) policy allows you to enforce various attack detection and prevention techniques on network traffic. You can configure the device to generate a system alarm when IDP flow policy violations occur.
Replay attacks—A replay attack is a network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. You can configure the device to generate a system alarm when a replay attack occurs.
The syslog messages are included in the following cases:
Failed symmetric key generation
Failed asymmetric key generation
Failed manual key distribution
Failed automated key distribution
Failed key destruction
Failed key handling and storage
Failed data encryption or decryption
Failed key agreement
Failed cryptographic hashing
Failed authentication of the received packets
Decryption error due to invalid padding content
Mismatch in the length specified in the alternative subject field of the certificate received from a remote VPN peer device.
Alarms are raised based on syslog messages. Every failure is logged, but an alarm is generated only when a threshold is reached.
To view the alarm information, run the show security alarms command. The violation count and the alarm do not persist across system reboots. After a reboot, the violation count resets to zero, and the alarm is cleared from the alarm queue.
After appropriate actions have been taken, you can clear the alarm. The alarm remains in the queue until you clear it (or until you reboot the device). To clear the alarm, run the clear security alarms command.
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
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.
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.
Example: Setting an Audible Alert as Notification of a Security Alarm
This example shows how to configure a device to generate a system alert beep when a new security event occurs. By default, alarms are not audible. This feature is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, and SRX1500 devices and vSRX instances.
No special configuration beyond device initialization is required before configuring this feature.
In this example, you set an audible beep to be generated in response to a security alarm.
To set an audible alarm:
- Enable security alarms.user@host# edit security alarms
- Specify that you want to be notified of security alarms
with an audible beep.[edit security alarms]user@host# set audible
- If you are done configuring the device, commit the configuration.[edit security alarms]user@host# commit
To verify the configuration is working properly, enter the show security alarms detail command.
Example: Generating Security Alarms in Response to Potential Violations
This example shows how to configure the device to generate a system alarm when a potential violation occurs. By default, no alarm is raised when a potential violation occurs. This feature is supported on SRX300, SRX320, SRX340, SRX345, SRX550HM, and SRX1500 devices and vSRX instances.
No special configuration beyond device initialization is required before configuring this feature.
In this example, you configure an alarm to be raised when:
The number of authentication failures exceeds 6.
The cryptographic self-test fails.
The non-cryptographic self-test fails.
The key generation self-test fails.
The number of encryption failures exceeds 10.
The number of decryption failures exceeds 1.
The number of IKE Phase 1 failures exceeds 10.
The number of IKE Phase 2 failure exceeds 1.
A replay attack occurs.
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the  hierarchy level, and then enter commit from configuration mode.
To configure alarms in response to potential violations:
- Enable security alarms.user@host# edit security alarms
- Specify that an alarm should be raised when an authentication
failure occurs.[edit security alarms potential-violation]user@host# set authentication 6
- Specify that an alarm should be raised when a cryptographic
self-test failure occurs.[edit security alarms potential-violation]user@host# set cryptographic-self-test
- Specify that an alarm should be raised when a non-cryptographic
self-test failure occurs.[edit security alarms potential-violation]user@host# set non-cryptographic-self-test
- Specify that an alarm should be raised when a key generation
self-test failure occurs.[edit security alarms potential-violation]user@host# set key-generation-self-test
- Specify that an alarm should be raised when an encryption
failure occurs.[edit security alarms potential-violation]user@host# set encryption-failures threshold 10
- Specify that an alarm should be raised when a decryption
failure occurs.[edit security alarms potential-violation]user@host# set decryption-failures threshold 1
- Specify that an alarm should be raised when an IKE Phase
1 failure occurs.[edit security alarms potential-violation]user@host# set ike-phase1-failures threshold 10
- Specify that an alarm should be raised when an IKE Phase
2 failure occurs.[edit security alarms potential-violation]user@host# set ike-phase2-failures threshold 1
- Specify that an alarm should be raised when a replay attack
occurs.[edit security alarms potential-violation]user@host# set replay-attacks
From configuration mode, confirm your configuration by entering the show security alarms command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
If you are done configuring the device, enter commit from configuration mode.
To confirm that the configuration is working properly, from operational mode, enter the show security alarms command.