Troubleshooting Scenario Questions

Create a static route to the ISP router and enable OSPF on the virtual router.

Why it fails: A static route to the ISP router is not required for OSPF adjacency; OSPF uses multicast Hellos on the directly connected subnet. While enabling OSPF on the virtual router is necessary, the static route is irrelevant and does not address the missing interface area assignment.

Configure a loopback interface and assign it to the same OSPF area as the ISP router.

Why it fails: While a loopback interface can be used for OSPF router ID stability, it is not required to form an adjacency. The adjacency forms on the physical interface that connects to the ISP router, not the loopback. Without enabling OSPF on the virtual router and the physical interface, the loopback alone will not help.

Set the interface type to Layer 2 and enable OSPF on the Layer 2 interface.

Why it fails: OSPF is a Layer 3 routing protocol and cannot be enabled on a Layer 2 interface. The interface must be a Layer 3 interface with an IP address. Changing to Layer 2 would break routing and prevent adjacency formation.

The API Key is expired.

Why it fails: An expired API key typically returns 401 Unauthorised, since the credential fails authentication before authorisation is evaluated. Expiry governs identity validation, not permission. It would be correct if the API rejected the credential outright with a 401 response.

The JSON body is malformed.

Why it fails: A malformed JSON body would return 400 Bad Request, since the server rejects the payload's syntax before evaluating authorisation. JSON formatting governs request parsing, not identity. It would be the answer if the API returned a schema or parse error on a POST or PUT.

The API endpoint URL is incorrect.

Why it fails: An incorrect endpoint URL returns 404 Not Found, because the server cannot match the requested resource path. URL correctness governs routing, not permission. It would be correct if the script hit a valid host but a non-existent path, producing a 404 rather than a 403.

Mismatched OSPF area IDs

Why it fails: Mismatched area IDs would prevent adjacency, but the neighbor state would typically be DOWN or INIT, not EXSTART. EXSTART indicates that the routers are attempting to exchange database description packets but are having issues with master/slave election. Area mismatch is not the cause of EXSTART.

Duplicate router IDs

Why it fails: Duplicate router IDs can cause OSPF issues, but typically they lead to a neighbor state of DOWN or 2-WAY, not EXSTART. In EXSTART, the routers have already discovered each other and are attempting to exchange databases. Duplicate router IDs would prevent adjacency earlier in the process.

Incorrect OSPF hello interval

Why it fails: An incorrect hello interval would prevent the routers from discovering each other, resulting in a neighbor state of DOWN or INIT. It would not allow the adjacency to progress to EXSTART. Therefore, this is not the cause of the EXSTART state.

Verify that the security policy includes a rule allowing traffic from the User-ID agent to the firewall's management interface.

Why it fails: User-ID agent communication typically occurs on the dataplane, not the management interface, and is often implicitly allowed. If the agent is connected, as stated, then the necessary connectivity is already in place. Adding a policy for management interface traffic is not the correct next step for troubleshooting user mapping.

Ensure that the LDAP server profile uses port 389 for LDAP over SSL.

Why it fails: LDAP over SSL typically uses port 636, not 389. Port 389 is for standard LDAP or StartTLS. Using the wrong port would prevent the LDAP connection, but the scenario states that the firewall can reach the LDAP server, implying the connection is working. Therefore, this is unlikely to be the cause of user identification failure.

Check that the firewall's management interface has a default gateway configured.

Why it fails: The management interface default gateway is important for management access, but User-ID traffic typically uses the dataplane interfaces. If the firewall can already reach the LDAP server, the management gateway is likely not the issue. This check is less relevant to User-ID mapping failures.

Update the hardware firmware.

Why it fails: Updates should be planned, not used for troubleshooting.

Perform a factory reset of the firewall.

Why it fails: Extreme and unnecessary.

Change the encryption algorithm

Why it fails: Changing the encryption algorithm alters the IPsec or SSL proposal rather than gathering diagnostic evidence, so it cannot troubleshoot GlobalProtect connectivity. It is tempting because adjusting crypto settings is the correct action when a peer rejects the proposed suite during IKE or SSL negotiation, not for general connectivity diagnosis.

Reload the firewall firmware

Why it fails: Reloading firewall firmware reboots the dataplane and interrupts all sessions without isolating the GlobalProtect fault, so it cannot troubleshoot connectivity. It is tempting because a firmware reload is the correct action when the device is unresponsive or running corrupted software, not for diagnosing tunnel or authentication failures.

Restart the management plane

Why it fails: Restarting the management plane disrupts administrative access and does not diagnose tunnel, authentication or routing faults, so it cannot troubleshoot GlobalProtect connectivity. It is tempting because a management-plane restart is a legitimate remedy when the web UI or commit process hangs, not for client connectivity faults.

show system processes

Why it fails: show system processes lists management-plane daemons and resource usage, revealing nothing about OSPF adjacencies or link states. It is tempting for general platform health checks, where it would be the right command, but OSPF troubleshooting needs show routing protocol ospf neighbour and related routing commands.

show hardware

Why it fails: show hardware reports chassis, interface and component inventory, providing no OSPF adjacency, area or link-state detail. It is tempting for verifying interface up/down status during outages, where it would be correct, but OSPF troubleshooting requires show routing protocol ospf neighbour and show routing protocol ospf commands.

show log routing

Why it fails: show log routing displays routing daemon log entries, which may hint at OSPF events but does not expose neighbour states, link-state database contents or interface timers directly. It is tempting because logs often reveal protocol errors, yet the expected OSPF commands are show routing protocol ospf neighbour and show routing protocol ospf.

Missing certificate on the gateway

Why it fails: A missing gateway certificate breaks the TLS handshake, so the tunnel never establishes and no internal traffic flows at all; the stem describes a client that connects yet cannot reach resources, which is a routing symptom. Certificate absence is the right diagnosis when GlobalProtect fails at authentication or connection setup.

Missing default route on the client machine

Why it fails: GlobalProtect delivers internal routes to the client through the tunnel's virtual adapter, so a missing default route on the endpoint does not explain failure to reach internal resources; internet-bound traffic would break instead. A missing default route is the correct diagnosis when the client connects but cannot reach external destinations.

Incorrect zone on the tunnel interface

Why it fails: An incorrect zone on the tunnel interface is a policy or security-zone misconfiguration, not a routing issue, so it falls outside the fault class the question asks about. Zone assignment is the correct diagnosis when the tunnel is up and routes exist but security policy silently drops the permitted traffic.

The firewall uses the virtual router associated with the egress interface to make the routing decision.

Why it fails: The egress interface's virtual router is not used for the initial routing lookup. Routing decisions are based on the ingress virtual router. The egress interface is determined by the route lookup result. If the route points to an interface in a different VR, the packet may be dropped. So the egress VR does not drive the decision.

The firewall uses the virtual router with the lowest administrative distance for the destination network.

Why it fails: Administrative distance is used within a virtual router to select the best route among multiple routing sources. It does not determine which virtual router to use. Virtual router selection is based on ingress interface, not on administrative distance. The firewall does not compare routes across different virtual routers by default.

The firewall uses the virtual router that has a default route configured.

Why it fails: Having a default route in a virtual router does not dictate its use for a packet. The ingress interface determines the virtual router. If the ingress VR does not have a route to the destination, the packet is dropped, even if another VR has a default route. Default routes are only considered within the context of the ingress virtual router.

The server's internal firewall status.

Why it fails: A 400 response originates from the API endpoint parsing the request, so the server's own firewall state cannot produce it; malformed JSON, headers or parameters must be inspected. Checking local firewall status suits connectivity failures such as refused or dropped connections, not a syntactically invalid request reaching the service.

The network latency between client and firewall.

Why it fails: A 400 Bad Request means the firewall rejected the request as malformed, so latency is irrelevant; the payload, headers, content type or URI syntax must be validated. Latency checks suit diagnosing timeouts or slow responses, where the client waits rather than receiving an immediate client-error rejection.

The API Key expiry date.

Why it fails: An expired API key yields 401 Unauthorised or 403 Forbidden, not 400 Bad Request, because authentication is evaluated separately from request syntax. Checking key expiry is the right first step when the firewall returns authentication or authorisation errors, indicating the credential rather than the payload is at fault.

Dashboard

Why it fails: The Dashboard shows widget-based summaries such as top applications and threat counts, not raw system log entries. Hardware fault diagnosis needs the detailed system log under Monitor > Logs > System. Dashboards are used for at-a-glance operational monitoring, not event-level troubleshooting.

Device > Setup

Why it fails: Device > Setup holds device configuration, licences and updates, not log output. System logs for hardware faults appear under Monitor > Logs > System. Setup pages are used when configuring management settings or installing content updates, not for reading runtime hardware events.

Network > Interfaces

Why it fails: Network > Interfaces configures interface settings such as zones, IP addresses and link state, but displays no log entries. Hardware troubleshooting requires the system log view under Monitor > Logs > System. Interface pages are used when assigning zones or configuring Layer 2/3 addressing.

The interface is not configured as a Layer 3 interface in the Network > Interfaces section.

Why it fails: If the interface were not Layer 3, it would not have an IP address or be assignable to a virtual router. The scenario states it is a Layer 3 interface, so this is not the cause. OSPF requires a Layer 3 interface, and the engineer already configured it as such; therefore, the lack of adjacency is due to another missing configuration.

The interface is not assigned to a security zone.

Why it fails: While assigning a zone is necessary for security policy enforcement, OSPF adjacencies are formed at the network layer and do not require a security zone. OSPF packets are allowed by default in the 'trust' zone if the zone is assigned, but the lack of a zone would not prevent OSPF from forming adjacencies; it would only affect security policy application.

The virtual router does not have a static route to the OSPF neighbor.

Why it fails: OSPF is a dynamic routing protocol and does not require static routes to neighbors. OSPF uses multicast hello packets to discover neighbors on directly connected interfaces. Static routes are not needed for adjacency formation; they are used for other purposes, such as reaching remote networks not learned via OSPF.

Increase the tunnel encryption level

Why it fails: Raising tunnel encryption changes the IPsec proposal, which is negotiated only after the client reaches the gateway; it cannot resolve an unreachable gateway. It is tempting because encryption mismatches do break established tunnels, but that produces negotiation or phase failures, not a pre-connection reachability error.

Check the local PC's DHCP settings

Why it fails: DHCP settings only affect IP address assignment; the 'Gateway not reachable' error indicates the client cannot reach the GlobalProtect portal or gateway address, so local addressing is not the fault. It is tempting because DHCP misconfiguration does break connectivity, but that would produce an address or DNS failure instead.

Clear the routing cache on the client

Why it fails: Clearing the routing cache is not a GlobalProtect troubleshooting step, and no such client-side cache exists for this error. It is tempting because stale routes do cause reachability failures in general networking, but the gateway-unreachable condition stems from portal address, certificate or firewall reachability issues.