Network Security
Monitor Your IPSec VPN Tunnel
Table of Contents
Expand All
|
Collapse All
Network Security Docs
-
- Security Policy
-
- Security Profile Groups
- Security Profile: AI Security
- Security Profile: WildFire® Analysis
- Security Profile: Antivirus
- Security Profile: Vulnerability Protection
- Security Profile: Anti-Spyware
- Security Profile: DNS Security
- Security Profile: DoS Protection Profile
- Security Profile: File Blocking
- Security Profile: URL Filtering
- Security Profile: Data Filtering
- Security Profile: Zone Protection
-
- Policy Object: Address Groups
- Policy Object: Regions
- Policy Object: Traffic Objects
- Policy Object: Applications
- Policy Object: Application Groups
- Policy Object: Application Filter
- Policy Object: Services
- Policy Object: Auto-Tag Actions
- Policy Object: Devices
-
- Uses for External Dynamic Lists in Policy
- Formatting Guidelines for an External Dynamic List
- Built-in External Dynamic Lists
- Configure Your Environment to Access an External Dynamic List
- Configure your Environment to Access an External Dynamic List from the EDL Hosting Service
- Retrieve an External Dynamic List from the Web Server
- View External Dynamic List Entries
- Enforce Policy on an External Dynamic List
- Find External Dynamic Lists That Failed Authentication
- Disable Authentication for an External Dynamic List
- Policy Object: HIP Objects
- Policy Object: Schedules
- Policy Object: Quarantine Device Lists
- Policy Object: Dynamic User Groups
- Policy Object: Custom Objects
- Policy Object: Log Forwarding
- Policy Object: Authentication
- Policy Object: Decryption Profile
- Policy Object: Packet Broker Profile
-
-
-
- The Quantum Computing Threat
- How RFC 8784 Resists Quantum Computing Threats
- How RFC 9242 and RFC 9370 Resist Quantum Computing Threats
- Support for Post-Quantum Features
- Post-Quantum Migration Planning and Preparation
- Best Practices for Resisting Post-Quantum Attacks
- Learn More About Post-Quantum Security
-
-
-
- Investigate Reasons for Decryption Failure
- Identify Weak Protocols and Cipher Suites
- Troubleshoot Version Errors
- Troubleshoot Unsupported Cipher Suites
- Identify Untrusted CA Certificates
- Repair Incomplete Certificate Chains
- Troubleshoot Pinned Certificates
- Troubleshoot Expired Certificates
- Troubleshoot Revoked Certificates
Monitor Your IPSec VPN Tunnel
Where Can I Use This? | What Do I Need? |
---|---|
| No license required |
Tunnel Monitoring
For a VPN tunnel, you can check connectivity to a destination IP address across the
tunnel. The network monitoring profile on the firewall allows you to verify
connectivity (using ICMP) to a destination IP address or a next hop at a specified
polling interval, and to specify an action on failure to access the monitored IP
address.
If the destination IP address is unreachable, you either configure the firewall to
wait for the tunnel to recover or configure an automatic failover to another tunnel.
In either case, the firewall generates a system log that alerts you to a tunnel
failure and renegotiates the IPSec keys to accelerate recovery.
To provide uninterrupted VPN service, you can use the Dead Peer Detection capability
along with the tunnel monitoring capability on the firewall. A DPD (Dead Peer
Detection) profile provides information about the number of seconds to wait in
between probes to detect if an IPSec peer site is alive or not. The liveness check
for IKEv2 is similar to DPD, which IKEv1 uses as the way to determine whether a peer
is still available.
You can also monitor the status of the tunnel. These monitoring tasks are described
in the following sections:
For troubleshooting purposes, you can Enable/Disable,
Refresh or Restart an IKE Gateway or IPSec
Tunnel.
Liveness Check
If there has only been outgoing traffic on all of the SAs associated with an IKE SA,
it is essential to confirm the liveness of the other endpoint to avoid black holes.
IKEv2 gateways can perform liveness checks to prevent sending messages to a dead
peer. Receipt of a fresh cryptographically protected message on an IKE SA or any of
its child SAs ensures the liveness of the IKE SA and all of its child SAs.
IKEv2 uses a liveness check (similar to Dead Peer Detection (DPD) in IKEv1)
to determine whether a peer is still available. The liveness check option is enabled
by default. Select NetworkNetwork ProfilesIKE Gateways and Advanced Options to configure the interval (in seconds) in
the Liveness Check for the IKE gateway. Note that you can configure the
liveness check option only if you have selected IKEv2 only mode or IKEv2
preferred mode for the Version in the IKE
Gateway (NetworkNetwork ProfilesIKE Gateways) configuration. If you select IKEv1 only mode
for the IKE Gateway Version, then the Advanced
Options would display IKEv1 configuration parameters such as,
Exchange mode and Dead Peer
Detection.
In IKEv2, the liveness check is achieved by any IKEv2 packet transmission or a
liveness check message that the gateway sends to the peer at a configurable
interval, 5 seconds by default. If there is no response, the sender attempts the
retransmission up to 10 times with increasing timeout (in seconds) for each retry as
follows:
5 + 10 + 20 + 40 + 60 + 60 + 60 + 60 + 60 + 60 = 7 minutes and 15 seconds
If it doesn’t get a response, the sender closes and deletes the IKE_SA and
corresponding CHILD_SAs. The sender will start over by sending out another
IKE_SA_INIT message.
After maximum retries are reached, the firewall will tear down phase 1 and phase 2
(child) SAs.