Troubleshooting Scenario Questions

HA1 keepalive failure is not detected

Why it fails: HA1 keepalive failure would cause failover if interface down, but not management.

HA2 link monitoring is not enabled

Why it fails: HA2 is for session sync, not failover trigger.

Session synchronization is not complete

Why it fails: Session sync status does not affect failover trigger.

The tunnel is configured as route-based instead of policy-based

Why it fails: Phase 2's 'no proposal chosen' means the IPsec proxy-IDs or traffic selectors do not match, not the tunnel type; route-based and policy-based both negotiate phase 2 identically. Route-based is chosen when the design needs VTI interfaces for dynamic routing or multiple subnets, so it is a design decision made before phase 2 negotiation.

The IKE gateway's local interface is down

Why it fails: A down local interface would prevent IKE phase 1 from completing at all, so it cannot explain a phase 2 proposal mismatch. It is tempting because interface state is a common VPN fault, but the stem confirms phase 1 already succeeded.

Dead peer detection is not enabled on the IKE gateway

Why it fails: Dead peer detection affects liveness checking of an established tunnel, not phase 2 proposal matching, so it cannot produce 'no proposal chosen'. It is tempting because DPD misconfiguration does cause tunnels to drop, but only after IKE and IPsec SAs have already negotiated.

Configure an Application Override policy for port 8080 to force the firewall to treat the traffic as the desired application.

Why it fails: Application Override is used to force the firewall to skip App-ID inspection for specific traffic and treat it as a specified application. While it can improve performance, it does not create a signature and may cause the firewall to misclassify other traffic on the same port. This option is wrong because it bypasses App-ID rather than enabling accurate identification, and it does not address the proprietary handshake.

Enable SSL decryption for all traffic on port 8080 to allow the firewall to inspect the payload.

Why it fails: SSL decryption is relevant only for SSL/TLS-encrypted traffic. The scenario describes a proprietary binary handshake, not SSL/TLS. Enabling decryption would not help the firewall recognize a non-SSL protocol and could introduce unnecessary overhead. This option is incorrect because it misdiagnoses the encryption state of the application and does not create a signature for the proprietary handshake.

Add a security policy rule that allows TCP port 8080 and relies on the firewall's default App-ID for that port.

Why it fails: Relying on a port-based rule does not help App-ID identify the application. The firewall's default App-ID for port 8080 may be generic or incorrect, leading to 'unknown-tcp'. Security policies should be application-based, but without a custom signature, the firewall cannot reliably classify the proprietary handshake. This option fails because it does not address the root cause of misidentification.

Disable preemption on the active firewall

Why it fails: Preemption governs which firewall resumes the active role after recovery; it has no bearing on whether configuration synchronises. Disabling it is tempting when failover behaviour looks wrong, but preemption is relevant only to role election scenarios, not to a sync-failure between peers.

Check the HA2 link session synchronization status

Why it fails: The HA2 link carries session synchronisation, not configuration, so checking it cannot resolve a configuration sync-failure. It is tempting because HA2 faults do cause failover problems, but configuration synchronisation travels over the HA1 link, which is where the fault lies.

Reboot both firewalls to clear the failure

Why it fails: Rebooting both firewalls discards evidence and risks an outage without addressing the underlying synchronisation fault. It is tempting as a quick reset, but reboots suit transient software faults; a persistent sync-failure requires inspecting HA1 connectivity, versions and commit state first.

The firewall's DNS settings

Why it fails: DNS settings on the firewall affect name resolution, not routing or forwarding of traffic to an IP-addressed internal server that other networks already reach. It is tempting because DNS failures do cause connection errors, and checking DNS would be right if users reached the server by hostname and resolution was failing.

The server's SSL certificate

Why it fails: An SSL certificate governs TLS negotiation for HTTPS sessions; it cannot block traffic when the security policy already permits it and other networks reach the server. It is tempting because certificate errors do break HTTPS access, and checking the certificate would be right if browsers showed trust warnings after connectivity succeeded.

The interface management profile

Why it fails: An interface management profile controls which administrative services, such as ping, SSH and HTTPS, respond on that interface; it does not govern dataplane forwarding of user traffic. It is tempting because it affects reachability testing, and it would be correct if pings or management access to the firewall interface itself failed.

show session info

Why it fails: This command shows active sessions but does not directly indicate performance bottlenecks.

show log traffic

Why it fails: This command shows traffic logs, which are for historical analysis, not real-time bottleneck identification.

Check the traffic logs for any denial events

Why it fails: Traffic logs record permitted and denied sessions, but an IPSec tunnel that re-establishes periodically points to Phase 2 lifetime or proxy-ID mismatch, which appears in system logs, not traffic logs. Traffic logs are correct when policy is suspected of blocking specific flows.

Reboot the firewall to clear any stale sessions

Why it fails: Rebooting clears state indiscriminately and destroys evidence needed to identify why the tunnel drops; it does not address the rekeying or lifetime mismatch causing the cycle. Rebooting is appropriate only when a firewall is unresponsive and no diagnostics are required.

Verify the routing table on both firewalls

Why it fails: Routing tables change only when links or dynamic protocols flap; a tunnel that returns without intervention indicates a negotiation parameter mismatch rather than a missing route. Verifying routing is correct when traffic fails consistently in one direction after a topology change.

Both firewalls have the same priority; the tie is broken by serial number, but due to simultaneous reboot, both came up as active. The solution is to reboot one firewall.

Why it fails: Equal priority is resolved by serial number, and simultaneous reboot does not make both peers active; rebooting one firewall does not correct the underlying election fault. Priority tie-breaking is relevant when configuring deterministic failover, but the actual cause is the HA timers and preemption behaviour during concurrent startup.

The HA configuration is set to active/active mode instead of active/passive.

Why it fails: Active/active mode would show both peers active, but the pair is configured active/passive, so this misreads the configuration rather than the reboot sequence. Active/active suits environments needing both devices forwarding simultaneously; here the fault lies in HA election after simultaneous startup, not in the mode setting.

The heartbeat interfaces are not configured on each firewall.

Why it fails: Missing heartbeat interfaces would prevent HA peering entirely, leaving peers in a non-functional or initial state rather than both reporting active. Heartbeat configuration matters when establishing HA links, but here the peers clearly communicate, so the split-brain stems from election timing after simultaneous reboot, not absent heartbeats.

User-ID

Why it fails: User-ID maps users to IPs and does not drop traffic.

SSL Decryption

Why it fails: SSL Decryption does not drop traffic; it decrypts or bypasses.

URL Filtering

Why it fails: URL Filtering blocks based on URL category but does not terminate existing sessions.

show counter global | match ipsec

Why it fails: Global counters aggregate packet and drop statistics per feature; they never expose IKEv2 payload contents, proposal mismatches or nonce exchanges. It is tempting because counters quickly reveal whether IKE packets arrive or are dropped, which is useful for confirming basic reachability before deeper troubleshooting.

show log system

Why it fails: System logs record discrete events such as tunnel up/down and commit results, not the step-by-step IKEv2 exchange detail needed to find a proposal or authentication mismatch. It is tempting because logs are the quickest first check, and would be the right choice for confirming whether the tunnel ever came up.

debug flow basic

Why it fails: debug flow basic traces session packet-path decisions such as routing, NAT and policy lookups, but it does not decode IKEv2 payloads or proposal exchanges. It is tempting because flow tracing is the standard tool for diagnosing why traffic is dropped, which would be the right choice for a data-plane forwarding failure.

Mismatched IKE version.

Why it fails: A mismatched IKE version prevents Phase 1 from completing, so the tunnel would never establish rather than flap after successful Phase 2 rekeys. Version mismatch is the right suspect when Phase 1 proposals fail and no security association forms.

Dead Peer Detection (DPD) interval too long.

Why it fails: A long DPD interval delays detection of a dead peer, but the logs show repeated Phase 2 rekeys, which points to mismatched proxy IDs or lifetime settings. DPD tuning suits scenarios where stale tunnels linger undetected, not active rekey churn.

Incorrect local or peer ID.

Why it fails: Incorrect local or peer IDs cause Phase 1 authentication to fail, so no tunnel would establish and no Phase 2 rekeys would appear. Identity mismatch is the right suspect when IKEv2 peers reject each other during initial negotiation.

Link failure

Why it fails: Link failure is a physical or logical interface fault that can trigger failover, but it does not describe the resulting state where both firewalls report active. It is tempting because link monitoring is central to HA operation, and it would be correct if the question asked what caused a failover event rather than naming the split state.

Active/Active

Why it fails: Active/Active describes an intentional configuration where both peers process traffic simultaneously, not a fault where both claim active state in a pair designed for failover. It is tempting because the name matches the symptom literally, and it would be correct when describing a deliberately load-sharing HA deployment.

Passive/Passive

Why it fails: Passive/Passive is a valid HA mode where neither device actively forwards until failover, so it cannot describe two firewalls simultaneously showing active. It is tempting because it is a recognised HA configuration, and it would be correct when describing a deployment where both peers remain standby.

The HA3 link is not configured or is misconfigured.

Why it fails: Incorrect. The HA3 link is used for packet forwarding in active/active mode, not for session synchronization in active/passive mode.

The passive firewall does not have management API access.

Why it fails: API access is not required for session synchronization.

The logging settings on both firewalls are different.

Why it fails: Logging settings do not affect session synchronization.

The source zone is incorrectly assigned; traffic is coming from a different zone.

Why it fails: If the zone were wrong, the traffic would not match the rule at all; but it hits a different rule, so zone is likely correct for that other rule.

The destination address is not in the specified subnet due to NAT.

Why it fails: If NAT is applied, the rule should use the pre-NAT or post-NAT address depending on configuration; but if the rule is for the DMZ zone, it should match the original destination before NAT.

The application 'ssl' does not match because the traffic is actually using TLS 1.3.

Why it fails: The ssl application identifier covers all SSL/TLS versions, including TLS 1.3.

Check that the session synchronization encryption is disabled to reduce latency.

Why it fails: Encryption is optional and does not cause sync failure; disabling it does not resolve the issue.

Validate that the heartbeat hold timer is set to a value greater than the failover delay.

Why it fails: Heartbeat hold timer influences failover timing, not session synchronization.

Confirm that the HA1 link is using the correct IP address and is in the same subnet.

Why it fails: HA1 is used for heartbeat and configuration sync, not session synchronization.