How To Troubleshoot Common FortiGate Configuration Issues

Most FortiGate configuration problems trace back to a short list of predictable culprits: a missing or wrong route, a firewall policy that does not match the traffic (or matches a broader policy first), NAT enabled on the wrong side, or a VPN proposal mismatch. Work the problem in order (interface, route, policy, NAT, then service or VPN parameters) and confirm each layer with the FortiGate’s own diagnostic tools before you change anything.

This guide gives you a practical, systematic approach to the issues we see most often as a managed firewall provider, current for FortiOS 7.4 and 7.6. FortiGate firewalls are powerful Next-Generation Firewalls (NGFWs), but that feature depth means small misconfigurations can produce confusing network behavior.

We’ll cover:

• Essential FortiGate troubleshooting tools and techniques.
• Solving common connectivity problems (no internet, can’t reach servers).
• Fixing firewall policy misconfigurations (traffic incorrectly blocked or allowed).
• Diagnosing VPN tunnel issues (IPsec and, on legacy releases, SSL-VPN).
• Choosing between GUI and CLI troubleshooting approaches.

What tools do you use to troubleshoot a FortiGate?

FortiGate ships with a full diagnostic toolkit in both the GUI and the CLI. Start in the GUI with the Log Viewer and Policy Lookup for fast checks, then drop to the CLI (diagnose debug flow and diagnose sniffer packet) when you need to see exactly how a packet is processed. Before you touch anything, cover the basics.

• Backups: Always back up your FortiGate configuration before making any changes. This is your safety net.
• Change Control: Follow your organization’s change control procedures. Document what you’re changing and why.
• Understand the Goal: Clearly define what the configuration should be doing. What traffic needs to be allowed or blocked? What should the VPN connect?

GUI Tools:

• Log Viewer: Your first stop. Check Forward Traffic, Event Logs (System, VPN, User), and UTM logs (Web Filter, IPS, etc.). Learn to filter effectively.
• Policy Lookup: Found under Policy & Objects -> Firewall Policy. Enter source/destination IPs, port, and protocol to see which policy should match the traffic.
• FortiView: Dashboards and visualizations of traffic, sources, destinations, and threats. Great for identifying top talkers or unusual patterns.
• Routing Monitor: Network -> Routing Monitor. View the active routing table.
• Packet Capture: Network -> Packet Capture. A GUI way to capture traffic on specific interfaces (though the CLI often offers more flexibility).

CLI Tools (The Powerhouse):

Access the CLI via SSH or the console widget in the GUI. The diagnose and get commands are essential:

• diagnose debug flow: The cornerstone of packet-level troubleshooting. Shows how a packet traverses the FortiGate, which policy it hits, and why it might be dropped. Set a filter (diagnose debug flow filter saddr <ip>, daddr <ip>, dport <port>), start the trace (diagnose debug flow trace start <n>), and enable output (diagnose debug enable). Remember to disable it (diagnose debug disable, diagnose debug reset) when done.
• diagnose sniffer packet any 'host <ip_address> and port <port_number>' 4 0 l: A powerful CLI packet sniffer. Replace any with a specific interface if needed. The filters (like host and port) are crucial.
• get system status: Basic device information (firmware version, serial number, uptime). Confirm which FortiOS build you’re on before you start.
• get system performance status: CPU/memory usage and session count. Useful for identifying resource exhaustion.
• diagnose sys session list: View active sessions in the session table. Can be filtered.
• diagnose vpn ike log filter name <phase1_name> followed by diagnose debug application ike -1 and diagnose debug enable: Debugs IPsec Phase 1 negotiation.

General Approach: troubleshoot systematically, from the bottom of the stack up.

1. Verify Layer 1/2: Is the interface physically up? Link lights? Correct VLAN?
2. Check Logs: Look for relevant deny or error messages.
3. Test Basic Connectivity: Use ping and traceroute (from clients and the FortiGate CLI: execute ping <destination>, execute traceroute <destination>).
4. Use Diagnostic Tools: Employ Policy Lookup, diagnose debug flow, or packet sniffing.
5. Verify Configuration Details: Double-check IPs, policies, routes, and VPN settings meticulously.

Why can’t users reach the internet or internal resources?

When traffic stops flowing, walk the path in order: interface, route, policy, NAT, then DNS. Nine times out of ten it’s a missing default route, a firewall policy that doesn’t match, or NAT that isn’t enabled on the outbound policy. Confirm the failing step with Policy Lookup or diagnose debug flow before changing anything.

Symptoms: Users report no internet access, inability to reach specific websites, or failure to connect to internal servers and applications.

Troubleshooting Steps:

1. Check Interface: In the GUI (Network -> Interfaces) or CLI (get system interface physical), verify the relevant interface (e.g., WAN, LAN) is up. Check IP addressing, netmask, and gateway (if applicable). Ensure cables are connected and functional.
2. Check Routing:
   • Internet: Does the FortiGate have a default route (0.0.0.0/0) pointing to the correct WAN interface/gateway? Use Routing Monitor (GUI) or get router info routing-table all (CLI).
   • Internal: Does the FortiGate have a route (static or dynamic) to the destination internal network?
3. Check Firewall Policies:
   • Go to Policy & Objects -> Firewall Policy.
   • Is there an enabled policy allowing the traffic from the source interface/zone/IP to the destination interface/zone/IP using the correct Service (port/protocol)?
   • NAT: For outbound internet access policies (e.g., LAN -> WAN), is NAT enabled and set to use the Outgoing Interface Address?
   • Policy Lookup Tool: Use this GUI tool first to see which policy ID should match.
   • diagnose debug flow: If Policy Lookup isn’t clear, use this CLI command (filtered for the specific traffic) to see exactly what’s happening: which policy ID is hit, or why it’s denied (e.g., denied by forward policy check (policy ID 0) often means no matching policy).
4. Check DNS:
   • Can the FortiGate resolve external domains? (Network -> DNS, check servers.) Use execute ping google.com from the CLI.
   • Are clients configured to use a working DNS server (often the FortiGate itself or internal DNS servers)? Check client IP configuration.
5. Check Logs: Filter Forward Traffic logs by the source IP. Look for “Action: Deny”. The “Reason” column or log details often indicate the cause (e.g., “Policy Deny”, “Reverse Path Check Failed”, “Blocked – Web Filter”).

Common Solutions:

• Adding or correcting static/default routes.
• Creating or modifying firewall policies (correcting interfaces, addresses, services, enabling the policy).
• Enabling NAT on the outbound internet policy.
• Configuring correct DNS servers on the FortiGate (Network -> DNS).
• Fixing client-side DNS settings.

Why is FortiGate blocking (or allowing) the wrong traffic?

FortiGate evaluates firewall policies top-down and applies the first match, so unexpected block or allow behavior is usually a policy-order or policy-scope problem, or a UTM security profile silently dropping the session. Identify the traffic, run Policy Lookup, then confirm with diagnose debug flow, which prints the exact policy ID that matched.

Symptoms: Legitimate traffic is unexpectedly blocked, or conversely, unwanted traffic is being allowed through.

Troubleshooting Steps:

1. Identify the Traffic: Note the Source IP, Destination IP, and Destination Port/Service involved.
2. Use Policy Lookup (GUI): Enter the traffic parameters. Does it match the policy you expect it to? Does it match a different policy unexpectedly?
3. Use diagnose debug flow (CLI): This is invaluable for policy issues. Filter (diagnose debug flow filter saddr <source_ip> daddr <dest_ip> dport <dest_port>) and run the trace (diagnose debug flow trace start 10, diagnose debug enable). The output shows msg="Allowed by Policy-ID=<id>" or the reason for denial. Remember to disable debug afterwards (diagnose debug disable, diagnose debug reset).
4. Review Policy Order: Policies are evaluated top-down and the first matching policy is applied. Is a broader policy placed above your specific policy, catching the traffic first? Re-order policies carefully.
5. Check Policy Details: Scrutinize the matching (or intended) policy:
   • Interfaces/Zones: Are the Incoming and Outgoing Interfaces correct?
   • Source/Destination Addresses: Are the Address Objects accurate? Do they contain the correct IPs or subnets? Avoid using “all” unless absolutely necessary.
   • Service: Is the correct port/protocol defined? Is it TCP, UDP, or ICMP? Avoid using “ALL”. Create custom services if needed.
   • Action: Is it set to Allow or Deny?
   • Security Profiles: If UTM features (Antivirus, Web Filter, IPS, Application Control, DNS Filter) are enabled on the policy, they could be blocking the traffic. Check the corresponding logs (e.g., Web Filter logs) for block events related to this traffic.
6. Check Logs: Filter Forward Traffic logs by source/destination IP and check the “Policy ID” column. Is it hitting the policy you expect? If denied, what’s the reason? Check UTM logs if Security Profiles are applied to the policy ID being hit.

Common Solutions:

• Re-ordering firewall policies.
• Correcting Source/Destination Address objects or Service definitions.
• Changing the policy Action (Allow/Deny).
• Adjusting or disabling specific Security Profiles on the policy (or creating exceptions within the profile).
• Making policies more specific (avoiding “all”).

How do you troubleshoot FortiGate VPN tunnels (IPsec and SSL-VPN)?

For IPsec, verify Phase 1 and Phase 2 come up (get vpn ipsec tunnel summary), then run the IKE debug to catch proposal, PSK, or selector mismatches. Confirm you have firewall policies in both directions with NAT disabled, and a route to the remote subnet. For SSL VPN, note that it is being phased out (see the warning below) and migrate remote access to IPsec.

Symptoms: VPN tunnels (site-to-site or remote access) fail to establish, disconnect frequently, or establish but don’t pass traffic.

IPsec Site-to-Site Troubleshooting:

1. Phase 1 (IKE): This establishes the secure management tunnel.
   • Check Status: GUI (Dashboard -> Network -> IPsec, or Monitor) or CLI (get vpn ipsec tunnel summary). Is it up?
   • Debug: Use CLI: diagnose vpn ike log filter name <your_phase1_name>, diagnose debug application ike -1, diagnose debug enable. Initiate the tunnel (e.g., with traffic) and watch the logs.
   • Common Errors: Proposal mismatches (Encryption, Authentication, DH Group, Key Lifetime must match exactly on both sides), Pre-Shared Key (PSK) mismatch, incorrect Remote Gateway IP or Peer ID. Modern deployments should use IKEv2 with AES-GCM and a strong DH group where both peers support it.
   • Verify: Double-check Phase 1 settings on both FortiGates (or the remote peer).
2. Phase 2 (IPsec): This negotiates the data tunnel parameters.
   • Check Status: GUI IPsec monitor (expand the tunnel details).
   • Debug: The IKE debug often shows Phase 2 negotiation too.
   • Common Errors: Proposal mismatches (Encryption/Authentication algorithms, PFS enablement, Key Lifetime) and selector mismatches (Local Address/Subnet and Remote Address/Subnet must be exact opposites, e.g., Local 192.168.1.0/24 <-> Remote 10.1.1.0/24). Using 0.0.0.0/0 can cause issues if not matched identically.
   • Verify: Check Phase 2 selectors and proposals on both peers.
3. Firewall Policies: You need policies to allow traffic into and out of the tunnel.
   • Policy: LAN -> tunnel_interface, Source=Local Subnet, Dest=Remote Subnet, Service=ALL (or specific), Action=Allow.
   • Policy: tunnel_interface -> LAN, Source=Remote Subnet, Dest=Local Subnet, Service=ALL (or specific), Action=Allow.
   • Important: Ensure these policies do not have NAT enabled.
4. Routing: The FortiGate needs a route pointing the remote subnet(s) toward the IPsec tunnel interface. This is often created automatically if configured in Phase 2, but verify using Routing Monitor or get router info routing-table all. The remote peer also needs a route back to your local subnet.
5. NAT Traversal: Required if either peer is behind a NAT device. Usually set to ‘Enable’ or ‘Forced’ on both ends (Network -> IPsec Tunnels -> Edit Phase 1).
6. Logs: Check VPN Events in the Event Log and Forward Traffic logs for traffic attempting to cross the VPN.

SSL-VPN Troubleshooting (legacy releases, FortiOS 7.6.2 and earlier): If you are on a release that still supports SSL VPN tunnel mode, the checks below apply. Treat this as a stopgap and prioritize the IPsec migration above.

1. Connectivity: Can the remote client reach the FortiGate’s public IP on the configured SSL VPN port (usually TCP/443 or TCP/10443)? Check any upstream firewalls. Check the FortiGate’s WAN interface Local-in Policy if restricting access.
2. Authentication:
   • Verify user credentials (local user, RADIUS, LDAP).
   • Check User & Authentication -> User Groups: Is the user in the correct group?
   • Check VPN -> SSL-VPN Settings: Are the correct groups assigned to the correct Portal in the Authentication/Portal Mapping?
   • Test backend servers: diagnose test authserver ldap <server_name> <username> <password>, diagnose test authserver radius <server_name> <username> <password>.
   • Check Logs: Event -> VPN Events or User Events.
3. Portal and Tunnel Settings: Confirm Tunnel Mode is enabled, split tunneling is configured correctly, and Source IP Pools are assigned and not exhausted (VPN -> Monitor -> SSL-VPN Monitor). You need a firewall policy from the SSL VPN tunnel interface (ssl.root by default) to the internal network(s), with NAT disabled.
4. Logs and Debug: Check Event Logs (VPN Events) and use SSL VPN debugs (diagnose debug application sslvpn -1, diagnose debug enable). Check Forward Traffic logs for traffic from the ssl.root interface.

Common Solutions:

• IPsec: Correcting mismatched Phase 1/2 proposals, PSKs, or selectors. Adding correct firewall policies and routes. Enabling NAT Traversal.
• SSL-VPN (legacy): Fixing authentication issues, correcting portal assignments, adding a firewall policy from ssl.root to LAN, and ensuring IP pool availability. Longer term, migrate to IPsec.

Should you troubleshoot a FortiGate from the GUI or the CLI?

Use both. Start in the GUI for fast, visual checks (Log Viewer, Policy Lookup, monitors), then move to the CLI when you need to see exactly how a packet is processed or debug a specific daemon. The GUI is faster for orientation; the CLI is where you get definitive answers.

• Start with the GUI: Use Log Viewer, Policy Lookup, and monitors for initial investigation and quick checks.
• Move to CLI for deep dives: When you need to see exactly how a packet is processed (diagnose debug flow), capture specific traffic (diagnose sniffer packet), or debug a specific process like IKE, the CLI is indispensable.
• Combine both: The most effective approach uses the GUI to identify potential issues (like a policy ID from logs), then the CLI to confirm the exact behavior or gather more detailed debug information.

Stay current: FortiOS versions and upgrade planning

A surprising number of “bugs” are resolved simply by running a mature, patched FortiOS build. As of mid-2026, the recommended production branches are FortiOS 7.4 and 7.6 (7.6.6 is widely recommended, with 7.6.7 available). FortiOS 8.0 was announced at Accelerate 2026 but is not yet recommended for production. Critically, FortiOS 7.2 reaches end-of-support in September 2026, so if you’re still on 7.2, plan your upgrade now.

FortiGate configuration issues can be frustrating, but they are rarely insurmountable. Adopt a systematic approach, lean on the built-in GUI and CLI diagnostics, and understand the common pitfalls around connectivity, policies, and VPNs. If you’d rather hand off day-to-day firewall management and monitoring, that’s exactly what our managed firewall services cover.

Sources

• Fortinet Document Library, SSL VPN tunnel mode replaced with IPsec VPN (FortiOS 7.6.7 Release Notes).
• Fortinet Document Library, Migration from SSL VPN tunnel mode to IPsec VPN.
• Fortinet Document Library, Debugging the packet flow (FortiOS 7.6 Administration Guide).
• Fortinet Document Library, diagnose debug (FortiOS 7.6 CLI Reference).
• Fortinet Documentation home: docs.fortinet.com.