A user can resolve the internal portal’s hostname, but the HTTPS connection times out. The firewall policy appears to allow it. Where do you look next?
Start with one connection. Use a packet capture to confirm that FortiGate sees the TCP SYN. Then use Debug Flow to see the firewall’s forwarding decision. Finally, use the capture to check whether the server replies. Each step gives you evidence for the next one.
Scope: This example uses IPv4 forwarded traffic and CLI syntax documented for FortiOS. The addresses and output excerpts are illustrative. The scenario was not run on a live firewall.
1. Confirm the packet reaches FortiGate
Client 10.10.10.25 on port2 connects to server 10.20.20.50 on TCP port 443. FortiGate should forward the traffic out port3. Run the checks in the relevant VDOM if your firewall uses multiple VDOMs.
diagnose sniffer packet any 'host 10.10.10.25 and host 10.20.20.50 and tcp port 443' 4 20Start a fresh connection from the client while the capture is running. Verbosity 4 shows interface names, and 20 limits the number of matching packets. Press Ctrl+C if the capture does not reach that limit.
| What you see | What to check next |
|---|---|
| No SYN on the expected ingress interface | Confirm the client used the expected destination IP and gateway. Check the upstream path and capture visibility. |
| SYN enters port2, but there is no corresponding egress packet | Use Debug Flow to check routing and policy. If NAT applies, account for the translated addresses in your egress capture filter. |
| SYN leaves port3, but no SYN-ACK comes back | Check the server listener, host firewall, gateway, and return path. |
| SYN-ACK comes back, but the client never sees it | Trace the reply to the client-side egress. Check session handling and the return route. |
2. Run a filtered Debug Flow
Coordinate with other administrators before resetting debug state on a shared firewall. Filter on the original client-to-server tuple, then reproduce the problem once. This directional filter targets the forward connection. Use the packet capture to follow both directions.
diagnose debug reset
diagnose debug flow filter clear
diagnose debug flow filter saddr 10.10.10.25
diagnose debug flow filter daddr 10.20.20.50
diagnose debug flow filter proto 6
diagnose debug flow filter dport 443
diagnose debug flow show function-name enable
diagnose debug flow trace start 20
diagnose debug enableAfter the test, stop the trace and clear its filters. Keep the capture window short, especially on firewalls that forward diagnostic output to a logging platform.
diagnose debug flow trace stop
diagnose debug disable
diagnose debug flow filter clear
diagnose debug reset3. Read the decision in the output
Start with lines for the same trace_id. Confirm the ingress interface and packet tuple, then look for the route and policy decisions. These excerpts are simplified. Message details can vary across FortiOS builds.
| Example output | What it tells you |
|---|---|
received a packet … from port2 | FortiGate processed a packet on port2. Confirm it belongs to the failing connection. |
find a route … via port3 | FortiGate selected port3. If you expected another interface, check the route and any policy routing or SD-WAN decision. |
Allowed by Policy-12 | Policy 12 allowed the forward packet. Check the egress capture and the server’s response. |
Denied by forward policy check (policy 0) | No applicable forward allow policy matched. Check interfaces, addresses, service, schedule, and user restrictions. |
When NAT is involved, record the tuple before and after translation. For an inbound VIP, start with the public destination and port, then check the mapped server IP and port on the internal leg. For source NAT, identify which source the server sees and follow the reply to that address. This routed HTTPS example expects no translation.
4. Verify the result with the original application
Suppose the trace shows the expected route and policy 12 allows the connection. The capture shows the SYN leaving port3, but no SYN-ACK returning. Check at the server or its gateway next.
If Debug Flow shows no output, confirm the VDOM and filters, then generate a fresh session. Hardware offload can limit what CPU-based diagnostics see. Correlate with a capture point that can observe the traffic before concluding that no packet arrived.
After correcting the cause, repeat the same client-to-server HTTPS test. Confirm the TCP handshake and load the actual portal. Record the ingress interface, selected egress, matched policy, and the observation that identified the fault.
References and related reading
Fortinet: Debugging the packet flow · Fortinet: Packet capture · Fortinet Community: VIP troubleshooting
If the same traffic crosses an IPsec tunnel, see FortiGate IPsec VPN Is Up but No Traffic Passes.