FortiGate Policy Route Configuration with Dual ISP Real-Life Examples

Managing internet traffic across multiple Internet Service Providers (ISPs) requires precise routing controls. Standard routing lookups only consider the destination IP address. However, modern enterprise networks often require routing decisions based on source IP, port numbers, or ingress interfaces. Master proper FortiGate policy route configuration to gain granular control over outbound paths without complex routing protocols.

In this comprehensive guide, you will learn how Policy-Based Routing (PBR) operates on FortiOS. You will configure policy routes to steer business-critical application traffic through a secondary ISP line while sending standard employee browsing through the primary link. We will cover prerequisites, GUI and CLI configuration steps, packet flow mechanics, verification commands, and troubleshooting workflows.

Real-Life Scenario: Multi-ISP Traffic Steering

Consider a medium-sized enterprise operating a local branch office. The site maintains two distinct internet connections:

• ISP-1 (Primary Commodity WAN): High bandwidth (1 Gbps), lower cost, but subject to variable latency. Used for general web traffic.
• ISP-2 (Secondary Dedicated WAN): Lower bandwidth (200 Mbps), higher cost, guaranteed low latency and strict SLA. Used for enterprise SaaS systems and partner API connectivity.

The network team must satisfy a strict requirement: All database replication and HTTPS application traffic originating from the internal application server (10.0.10.50) toward an external cloud partner (198.51.100.50) must egress through ISP-2. All other general outbound traffic from the internal network (10.0.10.0/24) must continue using ISP-1.

Standard destination-based static routing cannot achieve this because both internet connections reach the same external destination IP address over default routes. Implementing a policy route allows us to override the default routing table lookup specifically for traffic originating from our application server.

Lab Topology

The following diagram illustrates the lab setup for this tutorial:

                                  +-------------------+
                                  |   ISP-1 (Primary) |
                             +--->| Gateway:          |---> General Internet
                             |    | 192.0.2.254       |
                             |    +-------------------+
                             |
                      [wan1: 192.0.2.1/24]
                        +-----------+
[ Internal Subnet ]---->| FortiGate |
 10.0.10.0/24           | Firewall  |
 (Ingress: port1)       +-----------+
                      [wan2: 203.0.113.1/24]
                             |
                             |    +-------------------+
                             +--->| ISP-2 (Secondary) |
                                  | Gateway:          |---> Cloud Partner Application
                                  | 203.0.113.254     |     (198.51.100.50)
                                  +-------------------+

Example Addressing and Objects

The table below lists the network parameters, IP ranges, and firewall objects used in this tutorial. Modify these example values to match your specific environment.

Prerequisites

Before configuring a policy route on your FortiGate, ensure you have completed the following foundational tasks:

1. Both physical or virtual WAN interfaces (wan1 and wan2) are configured with correct IP addresses and link status is UP.
2. Valid static routes exist in the main routing table for both WAN links. FortiOS policy routes require an active route in the routing table (FIB) to the destination interface to be considered valid.
3. Firewall policies are created to allow traffic through BOTH egress interfaces. A policy route only steers traffic; firewall policies must explicitly permit the traffic and perform Source NAT (SNAT).

Step-by-Step GUI Configuration for FortiGate Policy Routes

Follow these steps to configure address objects, firewall policies, and the policy route in the FortiOS graphical user interface.

Step 1: Create Address Objects

1. Navigate to Policy & Objects > Addresses.
2. Click Create New > Address.
3. Define the internal application server:
   • Name: Host_AppServer
   • Type: Subnet
   • IP/Netmask: 10.0.10.50/32
   • Interface: Any
4. Click OK.
5. Click Create New > Address again to define the external destination:
   • Name: Ext_CloudPartner
   • Type: Subnet
   • IP/Netmask: 198.51.100.50/32
   • Interface: Any
6. Click OK.

Step 2: Create Gateway Firewall Policies

Policy routes select the outbound interface, but the firewall engine evaluates security rules afterward. You must create firewall policies for both egress interfaces.

1. Navigate to Policy & Objects > Firewall Policy.
2. Click Create New to set up the default ISP-1 rule:
   • Name: Allow_LAN_to_ISP1
   • Incoming Interface: port1
   • Outgoing Interface: wan1
   • Source: LAN_Subnet
   • Destination: all
   • Service: ALL
   • Action: ACCEPT
   • NAT: Enabled (Use Outgoing Interface Address)
3. Click OK.
4. Click Create New to set up the dedicated ISP-2 rule:
   • Name: Allow_AppServer_to_ISP2
   • Incoming Interface: port1
   • Outgoing Interface: wan2
   • Source: Host_AppServer
   • Destination: Ext_CloudPartner
   • Service: HTTPS
   • Action: ACCEPT
   • NAT: Enabled (Use Outgoing Interface Address)
5. Click OK.

Step 3: Add Policy Route

1. Navigate to Network > Policy Routes.
2. Click Create New.
3. Configure the policy route settings:
   • Type: Policy Route
   • Incoming interface: port1
   • Source Address: Choose Address Building Block, select Host_AppServer.
   • Destination Address: Choose Address Building Block, select Ext_CloudPartner.
   • Protocol: 6 (TCP)
   • Incoming Port / Destination Port: Set Destination Port range from 443 to 443.
   • Action: Forward Traffic
   • Outgoing interface: wan2
   • Gateway IP: 203.0.113.254
4. Click OK.

CLI Configuration

Engineers managing FortiGate devices often prefer the command-line interface for precision and speed. Below is the complete, validated CLI script to build this scenario.

Step 1: Configure Address Objects

config firewall address
    edit "Host_AppServer"
        set subnet 10.0.10.50 255.255.255.255
    next
    edit "Ext_CloudPartner"
        set subnet 198.51.100.50 255.255.255.255
    next
    edit "LAN_Subnet"
        set subnet 10.0.10.0 255.255.255.0
    next
end

Step 2: Configure Static Default Routes

Both gateways must exist in the routing configuration. We assign a higher administrative distance to the backup default route or keep equal distance if load distribution is planned.

config router static
    edit 1
        set gateway 192.0.2.254
        set device "wan1"
        set comment "Primary Default Route"
    next
    edit 2
        set gateway 203.0.113.254
        set device "wan2"
        set distance 10
        set comment "Secondary Default Route"
    next
end

Step 3: Configure Firewall Policies

config firewall policy
    edit 10
        set name "Allow_LAN_to_ISP1"
        set srcintf "port1"
        set dstintf "wan1"
        set srcaddr "LAN_Subnet"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set nat enable
    next
    edit 20
        set name "Allow_AppServer_to_ISP2"
        set srcintf "port1"
        set dstintf "wan2"
        set srcaddr "Host_AppServer"
        set dstaddr "Ext_CloudPartner"
        set action accept
        set schedule "always"
        set service "HTTPS"
        set nat enable
    next
end

Step 4: Configure Policy-Based Route

Now, build the exact config router policy entry to enforce traffic path selection.

config router policy
    edit 1
        set input-device "port1"
        set srcaddr "Host_AppServer"
        set dstaddr "Ext_CloudPartner"
        set protocol 6
        set start-port 443
        set end-port 443
        set gateway 203.0.113.254
        set output-device "wan2"
        set comments "Route HTTPS traffic from App Server via ISP-2"
    next
end

How the Traffic Flows

Understanding FortiOS packet processing is critical for accurate engineering and rapid troubleshooting. FortiGate evaluates packets passing through the system in a deterministic sequence.

1. Ingress & Stateful Session Check: A packet arrives on port1. FortiGate checks if this frame matches an existing active session in its state table. If it does, routing is bypassed, and the packet follows the established session paths.
2. Policy Route (PBR) Lookup: If the packet starts a new session (TCP SYN), FortiGate evaluates the active policy route table (config router policy) before searching the standard Forwarding Information Base (FIB).
3. PBR Match Verification: FortiGate compares the packet parameters against configured policy routes from top to bottom.
   • If criteria match (Source IP 10.0.10.50, Destination IP 198.51.100.50, Protocol 6, Port 443), FortiGate selects wan2 and next-hop 203.0.113.254.
   • FortiGate checks if a valid active route to destination 198.51.100.50 exists via wan2 in the main routing table. If verified, the policy route is applied.
4. Firewall Policy Lookup: Once the egress interface is determined (wan2), FortiGate searches security policies matching source interface port1 and destination interface wan2.
   • If policy rule 20 matches, the packet is accepted. If no security policy allows port1 to wan2, the packet is dropped immediately.
5. SNAT Processing: Policy 20 calls for NAT. FortiGate rewrites the source IP address from 10.0.10.50 to the interface address of wan2 (203.0.113.1).
6. Egress: FortiGate transmits the frame out of interface wan2 toward gateway 203.0.113.254.

Verification

After completing the configuration, verify that your policy route active status and routing matches function correctly.

1. Inspect Policy Route Status via CLI

To inspect active Policy-Based Routing entries loaded into the kernel, run:

get router info routing-table all

To view policy route details specifically, execute:

diagnose firewall pbr list

This command outputs active PBR details, internal IDs, hit counts, incoming/outgoing interfaces, and destination gateway definitions.

2. Trace Active Sessions

Generate application traffic from the application server toward 198.51.100.50:443. Then, filter active firewall sessions on the FortiGate:

diagnose sys session filter src 10.0.10.50
diagnose sys session filter dst 198.51.100.50
diagnose sys session list

Look at the output lines showing proto=6, outdev=wan2, and confirm source NAT is rewriting the IP address to 203.0.113.1.

Troubleshooting Policy Routing Issues

When policy routes fail to steer traffic as expected, systematic execution of diagnostic tools will identify the root cause quickly.

Diagnostic Workflow

Use the FortiGate debug flow engine to observe real-time routing decisions taken by the kernel.

Execute the following debug commands in sequence:

diagnose debug reset
diagnose debug flow filter saddr 10.0.10.50
diagnose debug flow filter daddr 198.51.100.50
diagnose debug flow filter port 443
diagnose debug flow show function-name enable
diagnose debug flow trace start 10
diagnose debug enable

Send test traffic from your server. The CLI output displays real-time processing logs similar to this snippet:

id=20085 trace_id=1 msg="allocate a new session-0004a123"
id=20085 trace_id=1 msg="find a route: flag=04000001 gw=203.0.113.254 via wan2"
id=20085 trace_id=1 msg="matched Policy Route id=1 to gateway 203.0.113.254 via wan2"
id=20085 trace_id=1 msg="allowed by Policy-20:"

When testing concludes, disable debugging immediately using this cleanup command:

diagnose debug disable
diagnose debug flow trace stop

Troubleshooting Matrix

Common Mistakes

• Forgetting Firewall Security Policies: A policy route determines egress interface, but does not allow traffic. If no security policy permits traffic from source interface to target egress interface, traffic is dropped.
• Omitting Main Routing Table Routes: FortiOS requires a matching active route entry in the standard routing table for policy routes to remain active. If the egress interface has no valid route to the destination in the main routing table, FortiGate bypasses the policy route.
• Incorrect Rule Order: FortiGate processes policy routes top-down. If a broad rule (e.g., matching source 10.0.10.0/24 to destination all) sits higher in the list, specific host rules below it will never match.
• Neglecting SNAT Requirements: ISP routers drop packets carrying internal RFC 1918 addresses. Always verify that outbound security policies perform Source NAT to the exit WAN interface IP or pool.

Production Considerations

Before implementing policy routes in mission-critical corporate environments, evaluate these strategic considerations:

Policy Routes vs. SD-WAN Rules

While policy routes remain reliable for static routing overrides, FortiOS SD-WAN offers modern alternatives. SD-WAN rules integrate dynamic performance SLA measurements (jitter, latency, packet loss) across multiple ISPs. Consider upgrading policy routes to SD-WAN rules if you require dynamic automatic failover based on WAN quality degradation rather than hard physical link failures.

Link Monitoring & Failover

Standard policy routes remain active as long as the underlying egress interface status stays UP. If ISP-2 suffers an upstream outage while its physical port remains connected, standard policy routes will continue forwarding traffic into the black hole. Pair static routes with config system link-monitor or migrate to SD-WAN to automatically invalidate routes when upstream health checks fail.

Session Management

Policy routes apply to new session establishment. Modifying policy routes while production applications run will not instantly alter active TCP connections already recorded in the session state table. Plan maintenance windows accordingly when adjusting traffic paths for persistent database or VoIP connections.

Related FortiGate Guides

• FortiGate SD-WAN dual ISP failover
• FortiGate session troubleshooting
• FortiGate HA and failover testing

Summary

Mastering FortiGate policy route configuration allows administrators to control multi-WAN traffic patterns precisely. By bypassing standard destination-only routing lookups, you can direct application-critical traffic over performant dedicated links while offloading background traffic to secondary circuits.

Always align your policy routes with proper firewall security rules, active static routes, and correct SNAT mechanisms. When traffic behavior deviates from design expectations, leverage diagnose debug flow commands to isolate routing and security decisions within FortiOS.