VPN Alarms, Audits, and Events

You can analyze and understand the cause of VPN related failures using the alarms that Junos OS generates.

A VPN alarm is an indication that the configured VPN is in a state that may require user intervention to resolve. You’ll see an alarm when the device reports a failure while monitoring the audited events. While an event is an occurrence that happens at a specific point of time, an alarm is an indication of failure state.

Note the following points when monitoring the alarms and events:

• Make sure you enable security event logging during the initial setup of the device using the [set security log cache] command. See cache (Security Log) for more details.

• Junos OS supports security event logging on the SRX300, SRX320, SRX340, SRX345, SRX550HM, and SRX1500 Firewalls and on the vSRX Virtual Firewalls.

• Every administrator has a unique set of privileges based on the roles such as audit-administrator, cryptographic-administrator, IDS-administrator, and security-administrator. The other administrators cannot modify security event logging after its is enabled by the authorized administrator.

A VPN failure triggers an alarm when the system monitors any of the following audited events:

• Authentication failures—You can configure the device to generate a system alarm when the number of packet authentication failures reaches a specified threshold.

• Encryption and decryption failures—You can configure the device to generate a system alarm when the number of encryption or decryption failures exceeds a specified threshold.

• IKE Phase 1 and IKE Phase 2 failures—Junos OS establishes Internet Key Exchange (IKE) security associations (SAs) during IKE Phase 1 negotiations. The security associations protect the IKE Phase 2 negotiations. You can configure the device to generate a system alarm when the number of IKE Phase 1 or IKE Phase 2 failures exceeds a specified limit.

• Self-test failures—After a device powers on or reboots, Junos OS runs a few tests on the device to verify the implementation of the security software. 
Self-tests ensure the correctness of cryptographic algorithms. The Junos-FIPS image performs self-tests automatically after the device powers on and runs the test continuously for key-pair generation. In either the domestic or FIPS images, you can configure self-tests to run according to a defined schedule, on demand, or immediately after key generation.
 You can also configure the device to generate a system alarm when a self-test fails.

• IDP flow policy attacks—You use an intrusion detection and prevention (IDP) policy to enforce various attack detection and prevention techniques on the network traffic. You can configure the device to generate a system alarm when an IDP flow policy violation occurs.

• Replay attacks—A replay attack is a network attack in which an attacker maliciously or fraudulently repeats or delays a valid data transmission event. You can configure the device to generate a system alarm when a replay attack occurs.

Junos OS generates system log messages (also called syslog messages) to record the events that occur on the device. You’ll notice syslog messages 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 signature

• Failed key agreement

• Failed cryptographic hashing

• IKE failure

• 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

Junos OS triggers alarms based on the syslog messages. While Junos OS logs every failure, it generates an alarm only when the 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. The alarm remains in the queue until you reboot the device or until you clear the alarm after taking the appropriate actions. To clear the alarm, run the clear security alarms command.

After a VPN tunnel comes up, Junos OS tracks the tunnel status related to tunnel down issues and negotiation failures. Junos OS also tracks successful events such as successful IPsec security association negotiations, IPsec rekey, and IKE security association rekeys. We use the term tunnel events to refer to these failure and success events.

For Phase 1 and Phase 2, Junos OS tracks the negotiation events for a given tunnel with the iked or the kmd process along with the events that occur in external processes such as the authd or the pkid. When a tunnel event occurs multiple times, the device maintains only one entry with the updated time and the number of times that event occurred.

Overall, Junos OS tracks 16 events–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, the device doesn't store an event unless the tunnel is down. Few of these events are listed below:

• Lifetime in kilobytes expired for IPsec security association.

• Hard lifetime of IPsec security association expired.

• IPsec security associations cleared as the corresponding delete payload received from the peer.

• Cleared unused redundant backup IPsec security association pairs.

• IPsec security associations cleared as corresponding IKE security association deleted.

Junos OS creates and removes AutoVPN tunnels dynamically. As a result, tunnel events corresponding to these tunnels are short lived. Not all tunnel events are associated with a tunnel, nevertheless, you can use them for debugging.

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 Virtual Firewall instances.

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 Virtual Firewall instances.