Use this workflow to troubleshoot access issues in a structured, repeatable way.
The goal is to confirm the requirement, identify the traffic path and enforcing firewall, and then verify policy, NAT, routing, and security profiles to make an informed decision aligned with organizational standards.
Before troubleshooting, capture the minimum details needed:
Source: user or device IP, hostname, username, location (office/home), network type (wired, Wi-Fi, VPN, ZPA)
Destination: FQDN or IP, URL or path, port or protocol (TCP/UDP), environment (production or non-production)
Application: browser or application name, version, recent updates
When: start time, frequency (always or intermittent), last known good
Expected behavior: what should work (login page, API call, RDP, etc.)
Error symptoms: screenshot, exact error text, HTTP code, timeout vs reset vs refused
Change context: recent policy, NAT, DNS, or application changes, maintenance, upgrades
Best practice: Ask for the exact destination FQDN and port and an approximate timestamp of a failed attempt. These two details significantly speed up log correlation.
From the client side or the closest test point:
Confirm IP configuration and default gateway
Verify DNS resolution (FQDN resolves to the expected IP)
Confirm the destination IP is correct (avoid split-DNS issues)
If applicable, validate using both:
FQDN (represents real user behavior)
Resolved IP (for pure network-level validation)
Determine how traffic flows from source to destination:
Perform a traceroute from the source or a similar network segment
Identify where the path stops or times out
Note the last reachable hop (often close to the enforcing firewall or router)
Look for unexpected hairpin routing (traffic detouring through remote sites)
Note: Traceroute shows routing hops, but the actual blocking point may still be a firewall inspecting traffic beyond the last visible hop.
Once the likely firewall or egress point is identified, validate the following:
Source zone and ingress interface (internal, VPN, DMZ, etc.)
Egress interface, ISP path, and virtual router (VR)
Traffic flow through the expected security stack (Zscaler, proxy, VPN, cloud security services)
If multiple firewalls are present, confirm:
Which device is the default gateway for the source subnet
Which device performs NAT or Internet breakout
Whether policy-based routing (PBR) is applied
On the enforcing firewall, verify the following to make an informed decision aligned with organizational standards:
Correct source and destination zones
Correct address objects or source subnets
Correct application and service definitions (App-ID vs port-based rules)
Rule order (first matching rule applies)
Required security profiles (AV, IPS, URL filtering, etc.)
No deny rule shadowing the intended allow rule
Tip: Always review rule hit counts and traffic logs around the failure timestamp.
Confirm NAT behavior for the affected traffic flow:
Source NAT is applied as expected (correct egress interface or IP pool)
Destination NAT is correct for inbound or published services
No overlapping NAT rules causing unintended translation
Symmetric routing is maintained (return traffic passes through the same firewall)
Common NAT-related symptoms:
Access works from some subnets but not others
Connection establishes, but the application fails after handshake
Remote systems see an unexpected source IP address
Review logs corresponding to the exact time of the failed attempt:
Traffic logs (allow or deny action, rule name)
Threat logs (IPS or AV detections)
URL filtering logs (blocked categories, SSL inspection issues)
System logs (routing changes, session exhaustion, HA events)
If no logs are observed:
Traffic may not be reaching this firewall
Incorrect zones or interfaces may be configured
Routing issues may be preventing forwarding
The client may not be generating traffic due to DNS or application issues
If policy or NAT changes require traffic re-evaluation:
Prefer clearing a specific session ID to minimize impact
Avoid clearing all sessions in production unless absolutely required and approved
After validation or changes:
Re-test from the same source (same user, device, and network)
Confirm the expected rule is being hit
Confirm correct NAT translation
Capture rule names, NAT rules, and log evidence
Document the following:
Issue summary
Root cause (policy, NAT, routing, DNS, or application-related)
Fix implemented
Any follow-up or preventive actions