Mastering FortiGate static route configuration is a fundamental skill for network and security administrators. A static default route serves as the ultimate path for outgoing traffic when no specific destination route exists in the routing table. Without a default route, a FortiGate firewall cannot send internal user traffic to external destinations on the internet.

In this tutorial, you will learn how to configure, verify, and troubleshoot an IPv4 static default route on a FortiGate firewall running FortiOS. We will cover both the Graphical User Interface (GUI) and the Command Line Interface (CLI), explain how packet processing works behind the scenes, and highlight critical production considerations such as route monitoring and failover.

Real-Life Scenario

Consider a branch office scenario for a corporate network. The local branch office deploys a standalone FortiGate appliance (labeled Branch-FW01) to protect its internal network and provide secure connectivity to the internet.

The enterprise network team has received a dedicated Ethernet handoff from an Internet Service Provider (ISP). The ISP provides a small static public subnet for the FortiGate WAN interface. The internal network hosts user workstations and local servers on a private IP subnet.

The primary business requirement is simple: all traffic originated from internal users destined for external internet destinations must route through the ISP’s default gateway. Additionally, the network engineering team requires clean verification steps to confirm forwarding behavior and clear troubleshooting procedures if connectivity breaks.

Lab Topology

The following ASCII diagram illustrates the logical network topology used in this configuration guide:

+-----------------------------+
|    Internal Workstations    |
|     Subnet: 10.0.10.0/24    |
+--------------+--------------+
               |
               | (LAN Interface: port2)
               | IP: 10.0.10.1/24
        +------+------+
        |  Branch-FW01|
        |  FortiGate  |
        +------+------+
               | IP: 203.0.113.2/30
               | (WAN Interface: port1)
               |
+--------------+--------------+
|         ISP Gateway         |
|       IP: 203.0.113.1       |
+--------------+--------------+
               |
        +------+------+
        |  Internet   |
        +-------------+

Example Addressing and Objects

The table below details the lab parameters, IP addresses, and network objects used throughout this tutorial. All public and private IP ranges strictly follow standard documentation RFCs.

Device / Object Name Interface / Role IP Address / Subnet Gateway / Next-Hop Description
Branch-FW01 port1 (WAN) 203.0.113.2/30 203.0.113.1 External interface connected to the ISP router.
Branch-FW01 port2 (LAN) 10.0.10.1/24 N/A Internal gateway for local user VLAN.
ISP Router Upstream Peer 203.0.113.1/30 N/A ISP next-hop gateway routing to the internet.
LAN_Subnet Address Object 10.0.10.0/24 N/A Firewall address object representing internal hosts.

Note: Ensure you replace these LAB/EXAMPLE values with the actual IP address parameters provided by your ISP and local network plan when deploying in production.

Prerequisites

Before configuring a static default route on your FortiGate firewall, verify that the following preliminary conditions are met:

  • Administrative access to the FortiGate GUI or CLI with read-write permissions.
  • Physical or virtual network link established on the WAN interface (port1) with correct link speed and duplex settings.
  • Valid static IP address assigned to the WAN interface (e.g., 203.0.113.2/30).
  • Upstream gateway IP address confirmed by your Internet Service Provider (e.g., 203.0.113.1).
  • Layer 2 reachability verified (the ISP gateway must reside in the same IP subnet as the local WAN interface).

Step-by-Step GUI Configuration

FortiOS provides an intuitive Graphical User Interface to create static routes. Follow these exact steps to complete the FortiGate static route configuration in the GUI.

Step 1: Navigate to Static Routes

Log in to the FortiGate web console. In the left-hand navigation menu, navigate to Network > Static Routes.

Note: GUI menu structures can vary slightly between FortiOS releases (e.g., FortiOS 6.4, 7.0, 7.2, and 7.4). If feature visibility is customized, ensure Routing features are enabled under System > Feature Visibility.

Step 2: Create a New Static Route

Click on Create New at the top left of the Static Routes pane to open the route editing window.

Step 3: Configure Route Parameters

In the New Static Route window, enter the following parameters:

  • Destination: Select Subnet. Leave the IP/Netmask field set to 0.0.0.0/0.0.0.0 (or 0.0.0.0/0). This defines a default route matching all IP addresses not explicitly listed in the routing table.
  • Gateway IP: Enter the next-hop IP address assigned by your provider. In our scenario, enter 203.0.113.1.
  • Interface: Select port1 from the drop-down menu. This specifies the physical or logical egress interface through which traffic reaches the gateway IP.
  • Administrative Distance: Leave this set to the default value of 10 unless you are configuring secondary path priorities.
  • Status: Ensure the toggle switch is set to Enabled.

Step 4: Save the Configuration

Click OK at the bottom of the screen. The new default route will now appear in the static route configuration list.

CLI Configuration

Configuring static routes via the FortiOS CLI is fast, precise, and ideal for scripting or remote management via SSH. FortiOS uses a standard hierarchical configuration structure using config, edit, set, next, and end.

To configure the static default route via CLI, execute the following command block:

config router static
    edit 0
        set dst 0.0.0.0 0.0.0.0
        set gateway 203.0.113.1
        set device "port1"
        set comment "Default route to primary ISP"
    next
end

Command Breakdown

  • config router static: Enters the static routing configuration context.
  • edit 0: Directs FortiOS to create a new, automatically assigned numerical index entry for this route.
  • set dst 0.0.0.0 0.0.0.0: Sets the destination network and netmask to match any destination IP address (default route).
  • set gateway 203.0.113.1: Defines the next-hop IP address where matching packets are forwarded.
  • set device "port1": Binds the route to the specific physical egress interface.
  • set comment "...": Adds a human-readable description for administrative documentation.
  • next and end: Saves the entry and exits the static routing configuration context to apply changes.

How the Traffic Flows

To administer enterprise firewalls effectively, you must understand how FortiOS processes packets entering and leaving the system. Routing is only one part of the packet evaluation lifecycle.

When an internal client on the LAN (e.g., 10.0.10.50) attempts to access an internet website (e.g., 198.51.100.1), the FortiGate processes the packet through the following sequential operations:

  1. Ingress Processing: The packet enters physical interface port2. The FortiGate inspects the layer 2 header and layer 3 packet details.
  2. Routing Lookup (FIB Check): The FortiGate kernel queries its Forwarding Information Base (FIB) to determine the egress interface and next-hop address for destination IP 198.51.100.1.
    • No specific route matches 198.51.100.1/32.
    • The kernel falls back to the default route 0.0.0.0/0.
    • The routing lookup identifies port1 as the egress interface and 203.0.113.1 as the next-hop gateway.
  3. Firewall Policy Lookup: Once the ingress interface (port2) and egress interface (port1) are determined, the firewall evaluates stateful security policies top-down.
    • A matching security policy must exist from incoming interface port2 to outgoing interface port1 matching source 10.0.10.0/24 and destination ALL.
    • If no policy matches, the packet is silently dropped by the implicit deny policy.
  4. Source Network Address Translation (SNAT): If the matching firewall policy has Source NAT enabled, the FortiGate translates the private source IP (10.0.10.50) to the public WAN interface IP (203.0.113.2).
  5. State Tracking and Session Creation: FortiGate creates an entry in its stateful session table (`diagnose sys session list`). Subsequent packets in this flow match the established session directly.
  6. Egress Forwarding: The packet exits interface port1 target destination 203.0.113.1 via Layer 2 MAC resolution (ARP).

Verification

After completing your FortiGate static route configuration, verify that the route is installed active in the Routing Information Base (RIB) and that end-to-end forward paths function correctly.

1. Verify Active Routes in the Kernel Routing Table

To display all active IPv4 routes currently installed in the routing table, execute the following CLI command:

get router info routing-table all

Expected output should include a line similar to the following:

S*      0.0.0.0/0 [10/0] via 203.0.113.1, port1

The S* symbol indicates that the entry is a Static route (S) and is currently selected as the active Default Candidate route (*). The bracketed numbers [10/0] represent the Administrative Distance (10) and Priority (0).

If you wish to query static routes specifically configured in the system database regardless of active status, run:

get router info routing-table static

2. Test Gateway Reachability

Verify that the FortiGate can successfully resolve and communicate with the ISP gateway IP using the system ping utility:

execute ping 203.0.113.1

If successful, test public reachability beyond the local ISP gateway to a known public address:

execute ping 198.51.100.1

3. Verify Layer 2 ARP Resolution

Ensure that the FortiGate has successfully resolved the Layer 2 MAC address of the upstream ISP gateway:

diagnose ip arp list

Look for an entry matching the ISP gateway IP 203.0.113.1 assigned to interface port1. If the state shows incomplete or missing, physical cabling, VLAN tagging, or provider gateway issues may exist.

Troubleshooting

If traffic fails to pass through the newly created static route, follow this structured, engineering-led troubleshooting methodology.

Common Symptoms and Likely Causes

Observed Symptom Likely Root Cause Verification Command / Action
Static default route missing from get router info routing-table all Egress interface link is down, or gateway IP is not in the interface’s subnet. Check physical link status using get system interface physical. Verify interface IP addressing.
Pings to ISP gateway succeed from FortiGate, but internal LAN clients cannot reach the Internet. Missing or misconfigured Firewall Policy, or SNAT (NAT) disabled on egress policy. Check Policy table under Policy & Objects > Firewall Policy. Confirm NAT toggle is enabled.
Default route installed, but pings to upstream gateway time out completely. Incorrect Gateway IP address, Layer 2 isolation, or ISP blocking ICMP traffic. Verify ARP resolution via diagnose ip arp list. Confirm gateway IP address with ISP support.

Advanced Troubleshooting with Debug Flow

When packets fail to route, the FortiOS packet trace tool reveals precisely how the packet processing engine handles the traffic.

CAUTION: Running debug commands on high-throughput production firewalls can cause high CPU utilization and fill terminal buffers. Always apply tight debug filters and turn off debugging immediately after collecting data.

Execute the following commands to trace a test packet from internal source host 10.0.10.50 targeting external IP 198.51.100.1:

diagnose debug reset
diagnose debug flow filter saddr 10.0.10.50
diagnose debug flow filter daddr 198.51.100.1
diagnose debug flow show console enable
diagnose debug enable
diagnose debug flow trace start 10

Generate traffic from the client host. Look for key trace output lines indicating routing decisions and policy evaluation:

id=20085 trace_id=1 msg="allocate a new session-0000a1b2"
id=20085 trace_id=1 msg="find a route: flag=00000001 gw-203.0.113.1 via port1"
id=20085 trace_id=1 msg="Allowed by Policy-1: SNAT"

If the debug trace indicates "No route to host" or "Action: drop", review your routing table or security policies respectively.

Cleanup Step: Always disable debugging after troubleshooting is completed:

diagnose debug disable
diagnose debug reset

Common Mistakes

Avoid these frequent configuration errors when deploying static default routes on FortiGate firewalls:

  • Gateway IP Outside Egress Subnet: FortiOS requires the static route gateway IP address to reside within the exact same network subnet as configured on the interface. For example, if port1 has IP 203.0.113.2/30, the gateway must be within 203.0.113.0/30 (e.g., 203.0.113.1). Assigning a gateway from a different subnet prevents the route from being installed into the active routing table.
  • Confusing Routing with Permissive Security: Creating a static default route tells the FortiGate where to send traffic, but it does not grant permission for traffic to pass. You must always create a corresponding IPv4 Firewall Policy matching ingress (LAN) and egress (WAN) interfaces with NAT enabled.
  • Omitting Outbound NAT on Broadband Links: Private IP addresses (RFC 1918 addresses such as 10.0.10.0/24) cannot route across the public internet. If NAT is disabled on your LAN-to-WAN policy, external internet routers will drop packets returning to private IP ranges.
  • Unintentional Route Distance Precedence: Default static routes carry an Administrative Distance of 10 by default. If you deploy dynamic routing protocols (such as OSPF or BGP) or SD-WAN interfaces without adjusting route distances, traffic may unexpectedly prefer alternate paths.

Production Considerations

While a basic static default route works effectively for simple networks, high-availability and enterprise enterprise environments require additional architecture considerations.

1. SD-WAN Integration vs. Standalone Static Routes

In modern enterprise deployments, direct standalone static default routes are often replaced by FortiGate SD-WAN rules. When configuring SD-WAN, a static default route points to the virtual sdwan interface instead of individual physical ports. SD-WAN then dynamically balances traffic across multiple physical ISP links based on performance metrics such as latency, jitter, and packet loss.

2. Gateway Link Health Monitoring

A static default route remains active in the FortiGate routing table as long as the local physical interface link status remains up (Layer 1/2 active). If an upstream ISP provider suffers an outage beyond their immediate gateway router, the FortiGate interface remains up, leaving dead traffic pointing to the static route.

To solve this, configure a Link Health Monitor (link-monitor) to continuously ping an reliable external upstream host (such as 1.1.1.1 or 8.8.8.8). If health checks fail, the FortiGate automatically removes the static default route from the active routing table, allowing dynamic convergence or secondary backup routes to take over.

config system link-monitor
    edit "ISP1-HealthCheck"
        set server "1.1.1.1"
        set srcintf "port1"
        set gateway-ip 203.0.113.1
    next
end

3. Dual ISP Redundancy (Active/Passive Failover)

If your location has two Internet providers (Primary ISP on port1, Backup ISP on port2), you can configure dual static default routes using Administrative Distance for automatic secondary failover:

  • Primary Route (ISP1): Gateway 203.0.113.1, Interface port1, Distance 10
  • Backup Route (ISP2): Gateway 198.51.100.254, Interface port2, Distance 20

FortiOS installs only the route with the lower Administrative Distance (10) into the active routing table. If the primary interface drops, the system withdraws the primary route and instantly installs the secondary route (Distance 20) into the routing table.

Summary

Configuring a default static route is an essential building block in any FortiGate deployment. It defines the path of last resort, directing internet-bound traffic from internal subnets out toward an upstream ISP gateway.

To successfully deliver outbound connectivity, remember the key operational steps:

  1. Define the destination 0.0.0.0/0 static route pointing to the local ISP next-hop gateway address.
  2. Verify that the route is actively installed in the kernel forwarding table using get router info routing-table all.
  3. Configure an accompanying firewall policy allowing traffic from ingress LAN to egress WAN interfaces with NAT enabled.
  4. Validate real-time flow performance and session state creation using debug tools and ping tests.

By mastering these static routing principles and leveraging link monitors or SD-WAN features, network engineers can ensure resilient, predictable outbound connectivity across all FortiGate deployment architectures.