Routing concepts

This section contains the following topics:

• Default route
• Adding or editing a static route
• Configuring FQDNs as a destination address in static routes
• Routing table
• Viewing the routing database
• Kernel routing table
• Route look-up
• Blackhole routes
• Reverse path look-up
• Asymmetric routing
• Routing changes
• Static route tags
• Defining a preferred source IP for local-out egress interfaces

Default route

The default route has a destination of 0.0.0.0/0.0.0.0, representing the least specific route in the routing table. It is a catch all route in the routing table when traffic cannot match a more specific route. Typically this is configured with a static route with an administrative distance of 10. In most instances, you will configure the next hop interface and the gateway address pointing to your next hop. If your FortiGate is sitting at the edge of the network, your next hop will be your ISP gateway. This provides internet access for your network.

Sometimes the default route is configured through DHCP. On some entry-level models, the WAN interface is preconfigured in DHCP mode. Once the WAN interface is plugged into the network modem, it will receive an IP address, default gateway, and DNS server. FortiGate will add this default route to the routing table with a distance of 5, by default. This will take precedence over any default static route with a distance of 10. Therefore, take caution when you are configuring an interface in DHCP mode, where Retrieve default gateway from server is enabled. You may disable it and/or change the distance from the Network > Interfaces page when you edit an interface.

Adding or editing a static route

To add a static route using the GUI:

1. Go to Network > Static Routes and click Create New.

2. Enter the following information:

   Dynamic Gateway	When enabled, a selected DHCP/PPPoE interface will automatically retrieve its dynamic gateway.
   Destination	Subnet Enter the destination IP address and netmask. A value of 0.0.0.0/0.0.0.0 creates a default route. Named Address Select an address or address group object. Only addresses with static route configuration enabled will appear on the list. This means a geography type address cannot be used. Internet Service Select an Internet Service. These are known IP addresses of popular services across the Internet.
   Interface	Select the name of the interface that the static route will connect through.
   Gateway Address	Enter the gateway IP address. When selecting an IPsec VPN interface or SD-WAN creating a blackhole route, the gateway cannot be specified.
   Administrative Distance	Enter the distance value, which will affect which routes are selected first by different protocols for route management or load balancing. The default is 10.
   Advanced Options	Optionally, expand Advanced Options and enter a Priority. When two routes have an equal distance, the route with a lower priority number will take precedence. The default is 1.

3. Click OK.

Configuring FQDNs as a destination address in static routes

You can configure FQDN firewall addresses as destination addresses in a static route, using either the GUI or the CLI.

In the GUI, to add an FQDN firewall address to a static route in the firewall address configuration, enable the Static Route Configuration option. Then, when you configure the static route, set Destination to Named Address.

To configure an FQDN as a destination address in a static route using the CLI:

config firewall address
    edit 'Fortinet-Documentation-Website'
        set type fqdn
        set fqdn docs.fortinet.com
        set allow-routing enable
    next
end

config router static
    edit 0
        set dstaddr Fortinet-Documentation-Website
        ...
    next
end

Routing table

A routing table consists of only the best routes learned from the different routing protocols. The most specific route always takes precedence. If there is a tie, then the route with a lower administrative distance will be injected into the routing table. If administrative distances are also equal, then all the routes are injected into the routing table, and Cost and Priority become the deciding factors on which a route is preferred. If these are also equal, then FortiGate will use Equal cost multi-path to distribute traffic between these routes.

Viewing the routing table in the GUI

You can view routing tables in the FortiGate GUI under Dashboard > Network > Static & Dynamic Routing by default. Expand the widget to see the full page. Additionally, if you want to convert the widget into a dashboard, click on the Save as Monitor icon on the top right of the page.

You can also monitor policy routes by toggling from Static & Dynamic to Policy on the top right corner of the page. The active policy routes include policy routes that you created, SD-WAN rules, and Internet Service static routes. It also supports downstream devices in the Security Fabric.

The following figure show an example of the static and dynamic routes in the Routing Monitor:

To view more columns, right-click on the column header to select the columns to be displayed:

Field	Description
IP Version	Shows whether the route is IPv4 or IPv6.
Network	The IP addresses and network masks of destination networks that the FortiGate can reach.
Gateway IP	The IP addresses of gateways to the destination networks.
Interfaces	The interface through which packets are forwarded to the gateway of the destination network.
Distance	The administrative distance associated with the route. A lower value means the route is preferable compared to other routes to the same destination.
Type	The type values assigned to FortiGate routes (Static, Connected, RIP, OSPF, or BGP): Connected: All routes associated with direct connections to FortiGate interfaces Static: The static routes that have been added to the routing table manually RIP: All routes learned through RIP RIPNG: All routes learned through RIP version 6 (which enables the sharing of routes through IPv6 networks) BGP: All routes learned through BGP OSPF: All routes learned through OSPF OSPF6: All routes learned through OSPF version 6 (which enables the sharing of routes through IPv6 networks) IS-IS: All routes learned through IS-IS HA: RIP, OSPF, and BGP routes synchronized between the primary unit and the subordinate units of a high availability (HA) cluster. HA routes are maintained on subordinate units and are visible only if you're viewing the router monitor from a virtual domain that is configured as a subordinate virtual domain in a virtual cluster.
Metric	The metric associated with the route type. The metric of a route influences how the FortiGate dynamically adds it to the routing table. The following are types of metrics and the protocols they are applied to: Hop count: Routes learned through RIP Relative cost: Routes learned through OSPF Multi-Exit Discriminator (MED): Routes learned through BGP. By default, the MED value associated with a BGP route is zero. However, the MED value can be modified dynamically. If the value was changed from the default, the Metric column displays a non-zero value.
Priority	In static routes, priorities are 0 by default. When two routes have an equal distance, the route with the lower priority number will take precedence.
VRF	Virtual routing and forwarding (VRF) allows multiple routing table instances to co-exist. VRF can be assigned to an Interface. Packets are only forwarded between interfaces with the same VRF.
Up Since	The total accumulated amount of time that a route learned through RIP, OSPF, or BGP has been reachable.

Viewing the routing table in the CLI

Viewing the routing table using the CLI displays the same routes as you would see in the GUI.

If VDOMs are enabled on the FortiGate, all routing-related CLI commands must be run within a VDOM and not in the global context.

To view the routing table using the CLI:

# get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       O - OSPF, IA - OSPF inter area
      
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
      
E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
 * - candidate default
Routing table for VRF=0
S*      0.0.0.0/0 [1/0] via 172.31.0.1, MPLS [1/0]via 192.168.2.1, port1 [1/0] via 192.168.122.1, port2
S       1.2.3.4/32 [10/0] via 172.16.100.81, VLAN100
C       10.10.2.0/24 is directly connected, hub
C       10.10.2.1/32 is directly connected, hub
O       10.10.10.0/24 [110/101] via 192.168.2.1, port1, 01:54:18
C       10.253.240.0/20 is directly connected, wqt.root
S       110.2.2.122/32 [22/0] via 2.2.2.2, port2, [3/3]
C       172.16.50.0/24 is directly connected, WAN1-VLAN50
C       172.16.60.0/24 is directly connected, WAN2-VLAN60
C       172.16.100.0/24 is directly connected, VLAN100
C       172.31.0.0/30 is directly connected, MPLS
C       172.31.0.2/32 is directly connected, MPLS
B       192.168.0.0/24 [20/0] via 172.31.0.1, MPLS, 00:31:43
C       192.168.2.0/24 is directly connected, port1
C       192.168.20.0/24 is directly connected, port3
C       192.168.99.0/24 is directly connected, Port1-VLAN99
C       192.168.122.0/24 is directly connected, port2
Routing table for VRF=10
C       172.16.101.0/24 is directly connected, VLAN101

Examining an entry:

B       192.168.0.0/24 [20/0] via 172.31.0.1, MPLS, 00:31:43

Value	Description
B	BGP. The routing protocol used.
192.168.0.0/24	The destination of this route, including netmask.
[20/0]	20 indicates an administrative distance of 20 out of a range of 0 to 255. 0 is an additional metric associated with this route, such as in OSPF.
172.31.0.1	The gateway or next hop.
MPLS	The interface that the route uses.
00:31:43	The age of the route in HH:MM:SS.

Viewing the routing database

The routing database consists of all learned routes from all routing protocols before they are injected into the routing table. This likely lists more routes than the routing table as it consists of routes to the same destinations with different distances. Only the best routes are injected into the routing table. However, it is useful to see all learned routes for troubleshooting purposes.

To view the routing database using the CLI:

# get router info routing-table database
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       O - OSPF, IA - OSPF inter area
      
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
     E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       > - selected route, * - FIB route, p - stale info
Routing table for VRF=0
S    *> 0.0.0.0/0 [1/0] via 172.31.0.1, MPLS
     *>           [1/0] via 192.168.2.1, port1
     *>           [1/0] via 192.168.122.1, port2
S    *> 1.2.3.4/32 [10/0] via 172.16.100.81, VLAN100
C    *> 10.10.2.0/24 is directly connected, hub
C    *> 10.10.2.1/32 is directly connected, hub
O    *> 10.10.10.0/24 [110/101] via 192.168.2.1, port1, 02:10:17
C    *> 10.253.240.0/20 is directly connected, wqt.root
S    *> 110.2.2.122/32 [22/0] via 2.2.2.2, port2, [3/3]
C    *> 172.16.50.0/24 is directly connected, WAN1-VLAN50
C    *> 172.16.60.0/24 is directly connected, WAN2-VLAN60
C    *> 172.16.100.0/24 is directly connected, VLAN100
O       172.31.0.0/30 [110/201] via 192.168.2.1, port1, 00:47:36
C    *> 172.31.0.0/30 is directly connected, MPLS

Selected routes are marked by the > symbol. In the above example, the OSPF route to destination 172.31.0.0/30 is not selected.

Kernel routing table

The kernel routing table makes up the actual Forwarding Information Base (FIB) that used to make forwarding decisions for each packet. The routes here are often referred to as kernel routes. Parts of this table are derived from the routing table that is generated by the routing daemon.

To view the kernel routing table using the CLI:

# get router info kernel
tab=254 vf=0 scope=0 type=1 proto=11 prio=0 0.0.0.0/0.0.0.0/0->0.0.0.0/0 pref=0.0.0.0
        gwy=172.31.0.1 flag=04 hops=0 oif=31(MPLS)
        gwy=192.168.2.1 flag=04 hops=0 oif=3(port1)
        gwy=192.168.122.1 flag=04 hops=0 oif=4(port2)
tab=254 vf=0 scope=0 type=1 proto=17 prio=0 192.168.122.98/255.255.255.255/0->1.1.1.1/32 pref=0.0.0.0 gwy=192.168.122.1 dev=4(port2)
tab=254 vf=0 scope=0 type=1 proto=17 prio=0 172.31.0.2/255.255.255.255/0->1.1.1.1/32 pref=0.0.0.0 gwy=172.31.0.1 dev=31(MPLS)
tab=254 vf=0 scope=0 type=1 proto=17 prio=0 192.168.2.5/255.255.255.255/0->1.1.1.1/32 pref=0.0.0.0 gwy=192.168.2.1 dev=3(port1)
tab=254 vf=0 scope=0 type=1 proto=11 prio=0 0.0.0.0/0.0.0.0/0->1.2.3.4/32 pref=0.0.0.0 gwy=172.16.100.81 dev=20(VLAN100)
tab=254 vf=0 scope=0 type=1 proto=17 prio=0 192.168.122.98/255.255.255.255/0->8.8.8.8/32 pref=0.0.0.0 gwy=192.168.122.1 dev=4(port2)

The kernel routing table entries are:

Value	Description
tab	Table number: It will either be 254 (unicast) or 255 (multicast).
vf	Virtual domain of the firewall: It is the VDOM index number. If VDOMs are not enabled, this number is 0.
type	Type of routing connection. Valid values include: 0 - unspecific 1 - unicast 2 - local 3 - broadcast 4 - anycast 5 - multicast 6 - blackhole 7 - unreachable 8 - prohibited
proto	Type of installation that indicates where the route came from. Valid values include: 0 - unspecific 2 - kernel 11 - ZebOS routing module 14 - FortiOS 15 - HA 16 - authentication based 17 - HA1
prio	Priority of the route. Lower priorities are preferred.
->0.0.0.0/0 (->x.x.x.x/mask)	The IP address and subnet mask of the destination.
pref	Preferred next hop along this route.
gwy	Gateway: The address of the gateway this route will use.
dev	Outgoing interface index: This number is associated with the interface for this route. If VDOMs are enabled, the VDOM is also included here. If an interface alias is set for this interface, it is also displayed here.

Route look-up

Route look-up typically occurs twice in the life of a session. Once when the first packet is sent by the originator and once more when the first reply packet is sent from the responder. When a route look-up occurs, the routing information is written to the session table. If routing changes occur during the life of a session, additional routing look-ups may occur.

FortiGate performs a route look-up in the following order:

1. Policy-based routes: If a match occurs and the action is to forward, traffic is forwarded based on the policy route.
2. Forwarding Information Base, otherwise known as the kernel routing table.
3. If no match occurs, the packet is dropped.

Searching the routing table

When there are many routes in your routing table, you can perform a quick search by using the search bar to specify your criteria, or apply filters on the column header to display only certain routes. For example, if you want to only display static routes, you may use "static" as the search term, or filter by the Type field with value Static.

Route look-up on the other hand provides a utility for you to enter criteria such as Destination, Destination Port, Source, Protocol and/or Source Interface, in order to determine the route that a packet will take. Once you click Search, the corresponding route will be highlighted.

You can also use the CLI for a route look-up. The CLI provides a basic route look-up tool.

To look-up a route in the CLI:

# get router info routing-table details 4.4.4.4
Routing table for VRF=0
Routing entry for 0.0.0.0/0
      Known via "static", distance 1, metric 0, best
      * 172.31.0.1, via MPLS distance 0
      * 192.168.2.1, via port1 distance 0
      * 192.168.122.1, via port2 distance 0

Blackhole routes

Sometimes upon routing table changes, it is not desirable for traffic to be routed to a different gateway. For example, you may have traffic destined for a remote office routed through your IPsec VPN interface. When the VPN is down, traffic will try to re-route to another interface. However, this may not be viable and traffic will instead be routed to your default route through your WAN, which is not desirable. Traffic may also be routed to another VPN, which you do not want. For such scenarios, it is good to define a blackhole route so that traffic is dropped when your desired route is down. Upon reconnection, your desired route is once again added to the routing table and your traffic will resume routing to your desired interface. For this reason, blackhole routes are created when you configure an IPsec VPN using the IPsec wizard.

For FortiOS 7.4.0, SSL VPN web mode, explicit web proxy, and interface mode IPsec VPN features will not work with the following configuration: An IP pool with ARP reply enabled is configured. This IP pool is configured as the source IP address in a firewall policy for SSL VPN web mode, in a proxy policy for explicit web proxy, or as the local gateway in the Phase 1 settings for an interface mode IPsec VPN. A matching blackhole route is configured for IP pool reply traffic. Configuring an IP pool as the source NAT IP address in a regular firewall policy works as before. For details, see Technical Tip: IP pool and virtual IP behaviour changes in FortiOS 6.4, 7.0, 7.2, and 7.4.

To create a blackhole route in the GUI:

1. Go to Network > Static Routes.
2. Click Create New. The New Static Route screen appears.
3. Specify a Destination type.
4. Select Blackhole from the Interface field.
5. Type the desired Administrative Distance.
6. Click OK.

Route priority for a Blackhole route can only be configured from the CLI.

Reverse path look-up

Whenever a packet arrives at one of the interfaces on a FortiGate, the FortiGate determines whether the packet was received on a legitimate interface by doing a reverse look-up using the source IP address in the packet header. This protects against IP spoofing attacks. If the FortiGate does not have a route to the source IP address through the interface on which the packet was received, the FortiGate drops the packet as per Reverse Path Forwarding (RPF) check. There are two modes of RPF – feasible path and strict. The default feasible RPF mode checks only for the existence of at least one active route back to the source using the incoming interface. The strict RPF check ensures the best route back to the source is used as the incoming interface.

To configure a strict Reverse Path Forwarding check in the CLI:

config system settings
    set strict-src-check enable
end

You can remove RPF state checks without needing to enable asymmetric routing by disabling state checks for traffic received on specific interfaces. Disabling state checks makes a FortiGate less secure and should only be done with caution for troubleshooting purposes.

To remove Reverse Path Forwarding checks from the state evaluation process in the CLI:

config system interface
    edit <interface_name>
        set src-check disable
    next
end

Asymmetric routing

Asymmetric routing occurs when request and response packets follow different paths that do not cross the same firewall.

In the following topology, traffic between PC1 and PC2 takes two different paths.

Traffic from PC1 to PC2 goes through the FortiGate, while traffic from PC2 to PC1 does not.

In TCP, if the packets in the request and response directions follow different paths, the FortiGate will block the packets, since the TCP three-way handshake is not established through the FortiGate.

Scenario 1: PC1 starts a TCP connection with PC2

1. The TCP SYN is allowed by the FortiGate.
2. The TCP SYN/ACK bypasses the FortiGate.
3. The TCP ACK is blocked by the FortiGate.
4. Subsequent TCP packets are blocked by the FortiGate.

Scenario 2: PC2 starts a TCP connection with PC1

1. The TCP SYN bypasses the FortiGate.
2. The TCP SYN/ACK is blocked by the FortiGate.
3. Subsequent TCP packets are blocked by the FortiGate.

In ICMP, consider the following scenarios.

Scenario 1: PC1 pings PC2

1. The ICMP request passes through the FortiGate. A session is created.
2. The ICMP reply bypasses the FortiGate, but reaches PC1. The ping is successful.
3. The ICMP request passes through the FortiGate, and it matches the previous session.
4. The ICMP reply bypasses the FortiGate, but it reaches PC1. The ping is successful.
5. Subsequent ICMP requests are allowed by the FortiGate.

Scenario 2: PC2 pings PC1

1. The ICMP request bypasses the FortiGate, but it reaches PC1.
2. The ICMP reply passes through the FortiGate. No session is matched, and the packet is dropped.
3. Subsequent ICMP replies are blocked by the FortiGate.

If an ICMP request does not pass through the FortiGate, but the response passes through the FortiGate, then by default it blocks the packet as invalid.

Permitting asymmetric routing

If required, the FortiGate can be configured to permit asymmetric routing.

To permit asymmetric routing:

config system settings
    set asymroute enable
end

This setting should be used only when the asymmetric routing issue cannot be resolved by ensuring both directions of traffic pass through the FortiGate.

When asymmetric routing is enabled and occurs, the FortiGate cannot inspect all traffic. Potentially malicious traffic may pass through and compromise the security of the network.

Asymmetric routing behaves as follows when it is permitted by the FortiGate:

TCP packets

Scenario 1: PC1 starts a TCP connection with PC2

1. The TCP SYN is allowed by the FortiGate. The FortiGate creates a session, checks the firewall policies, and applies the configuration from the matching policy (UTM inspection, NAT, traffic shaping, and so on).
2. The TCP SYN/ACK bypasses the FortiGate.
3. The TCP ACK is allowed by the FortiGate. The packet matches the previously created session.
4. Subsequent TCP packets are allowed by the FortiGate. The packets in the session can also be offloaded where applicable.

Scenario 2: PC2 starts a TCP connection with PC1

1. The TCP SYN bypasses the FortiGate.
2. The TCP SYN/ACK is allowed by the FortiGate. No session is matched. The packet passes to the CPU and is forwarded based on the routing table.
3. The TCP ACK bypasses the FortiGate.
4. Subsequent TCP packets are allowed by the FortiGate. The FortiGate acts as a router that only makes routing decisions. No security inspection is performed.

ICMP packets

Scenario 1: PC1 pings PC2

1. There is no difference from when asymmetric routing is disabled.

Scenario 2: PC2 pings PC1

1. The ICMP request bypasses the FortiGate, but it reaches PC1.
2. The ICMP reply passes through the FortiGate. No session is matched. The packet passes to the CPU and is forwarded based on the routing table.
3. Subsequent ICMP replies are allowed by the FortiGate. The FortiGate acts as a router that only makes routing decisions. No security inspection is performed.

UDP packets

Asymmetric routing does not affect UDP packets. UDP packets are checked by the session table regardless of asymmetric routing. A policy is required to allow UDP.

Routing changes

When routing changes occur, routing look-up may occur on an existing session depending on certain configurations.

Routing changes without SNAT

When a routing change occurs, FortiGate flushes all routing information from the session table and performs new routing look-up for all new packets on arrival by default. You can modify the default behavior using the following commands:

config system interface
    edit <interface>
        set preserve-session-route enable
    next
end

By enabling preserve-session-route, the FortiGate marks existing session routing information as persistent. Therefore, routing look-up only occurs on new sessions.

Routing changes with SNAT

When SNAT is enabled, the default behavior is opposite to that of when SNAT is not enabled. After a routing change occurs, sessions with SNAT keep using the same outbound interface as long as the old route is still active. This may be the case if the priority of the static route was changed. You can modify this default behavior using the following commands:

config system global
    set snat-route-change enable
end

By enabling snat-route-change, sessions with SNAT will require new route look-up when a routing change occurs. This will apply a new SNAT to the session.

Static route tags

When a static route is configured with a route tag, it is matched in the route map, and then used to set the route's metric and advertise to the BGP neighbor. In the following example, route tag 565 is used, and router R1 receives the advertised route from the FortiGate router R5.

To configure the FortiGate:

1. Configure the static route:

   config router static
       edit 1
           set dst 77.7.7.7 255.255.255.255
           set distance 2
           set device "R560"
           set tag 565
       next
   end

2. Configure the route map:

   config router route-map
       edit "map1"
           config rule
               edit 2
                   set match-tag 565
                   set set-metric 2301
               next
           end
       next
   end

3. Configure the BGP neighbor:

   config router bgp
       config neighbor
           edit "10.100.1.2"
               set route-map-out "map1"
           next
       end
   end

   On its neighbor side, router R1 receives the advertised route from the FortiGate router R5.

4. Verify the BGP routing table:

   # get router info routing-table bgp
   Routing table for VRF=0
   B       77.7.7.7/32 [20/2301] via 10.100.1.1 (recursive is directly connected, R150), 03:18:53, [1/0]

5. Verify the network community:

   # get router info bgp network 77.7.7.7/32
   VRF 0 BGP routing table entry for 77.7.7.7/32
   Paths: (1 available, best #1, table Default-IP-Routing-Table)
     Advertised to non peer-group peers:
      2.2.2.2 3.3.3.3 10.100.1.5 2000::2:2:2:2
     Original VRF 0
     20
       10.100.1.1 from 10.100.1.1 (5.5.5.5)
         Origin incomplete metric 2301, localpref 200, valid, external, best
         Last update: Wed Oct  5 16:48:28 2022

Defining a preferred source IP for local-out egress interfaces

The preferred source IP can be configured on a static route so that local-out traffic is sourced from that IP. In the following example, a source IP is defined per static route. Local traffic that uses the static route will use the source IP instead of the interface IP associated with the route.

To configure preferred source IPs for static routes:

1. Configure the static routes:

   config router static
       edit 22
           set dst 172.17.254.0 255.255.255.0
           set gateway 172.16.200.254
           set preferred-source 1.1.1.1
           set distance 2
           set device "port1"
       next
       edit 23
           set dst 172.17.254.0 255.255.255.0
           set gateway 172.16.203.2
           set preferred-source 1.1.1.2
           set distance 2
           set device "agg1"
       next
   end

2. Configure the primary DNS server IP address:

   config system dns
       set primary 172.17.254.148
   end

To verify the configuration:

1. Verify the kernel routing table:

   # get router info kernel 
   ...
   tab=254 vf=0 scope=0 type=1 proto=11 prio=1 0.0.0.0/0.0.0.0/0->172.17.254.0/24 pref=0.0.0.0
           gwy=172.16.200.254 flag=14 hops=0 oif=9(port1) pref=1.1.1.1
           gwy=172.16.203.2 flag=14 hops=0 oif=33(agg1) pref=1.1.1.2

2. Verify the routing table for 172.17.254.148:

   # get router info routing-table details 172.17.254.148
   Routing table for VRF=0
   Routing entry for 172.17.254.0/24
     Known via "static", distance 2, metric 0, best
     * vrf 0 172.16.200.254, via port1, prefsrc 1.1.1.1
     * vrf 0 172.16.203.2, via agg1, prefsrc 1.1.1.2

3. Run a sniffer trace after some traffic passes:

   # diagnose sniffer packet any "host 172.17.254.148" 4
   interfaces=[any]
   filters=[host 172.17.254.148]
   1.319811 port1 out 1.1.1.1.1371 -> 172.17.254.148.53: udp 43
   1.320095 port1 in 172.17.254.148.53 -> 1.1.1.1.1371: udp 310
   1.921718 port1 out 1.1.1.1.1371 -> 172.17.254.148.53: udp 27
   2.031520 port1 in 172.17.254.148.53 -> 1.1.1.1.1371: udp 213

   When DNS traffic leaves the FortiGate and is routed through port1, the source address 1.1.1.1 is used.