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 cache
• Route look-up
• Blackhole routes
• Reverse path look-up
• Asymmetric routing
• Routing changes

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 desktop 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 0.

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

end

config router static

edit 0

set dstaddr Fortinet-Documentation-Website

...

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 from 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 cache

The route cache contains recently used routing entries in a table. It is consulted before the routing table to speed up the route look-up process.

To view the route cache using the CLI:

# diagnose ip rtcache list

family=02 tab=254 vrf=0 vf=0 type=01 tos=0 flag=00000200
0.0.0.0@0->208.91.113.230@3(port1) gwy=192.168.2.1 prefsrc=192.168.2.5
ci: ref=0 lastused=1 expire=0 err=00000000 used=5 br=0 pmtu=1500

family=02 tab=254 vrf=0 vf=0 type=01 tos=0 flag=00000200
192.168.2.5@0->8.8.8.8@3(port1) gwy=192.168.2.1 prefsrc=0.0.0.0
ci: ref=0 lastused=0 expire=0 err=00000000 used=2 br=0 pmtu=1500

family=02 tab=254 vrf=0 vf=0 type=02 tos=8 flag=80000200
8.8.8.8@31(MPLS)->172.31.0.2@6(root) gwy=0.0.0.0 prefsrc=172.31.0.2
ci: ref=1 lastused=0 expire=0 err=00000000 used=0 br=0 pmtu=16436

family=02 tab=254 vrf=0 vf=0 type=02 tos=0 flag=84000200
192.168.20.6@5(port3)->192.168.20.5@6(root) gwy=0.0.0.0 prefsrc=192.168.20.5
ci: ref=2 lastused=0 expire=0 err=00000000 used=1 br=0 pmtu=16436

...

The size of the route cache is calculated by the kernel. However, you can modify it.

To modify the size of the route cache:

# config system global

set max-route-cache-size <number_of_cache_entries>

end

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 and the route cache. 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. Route Cache: If there are no matches, FortiGate looks for the route in the route cache.
3. Forwarding Information Base, otherwise known as the kernel routing table.
4. 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 using 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.

To create a blackhole route from 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 using 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 using the CLI:

# config system interface

edit <interface_name>

set src-check disable

next

end

Asymmetric routing

The firewall tries to ensure symmetry in its traffic by using the same source-destination combination in the original and reverse path. Asymmetric routing occurs when traffic in the returning direction takes a different path than the original. There may be various scenarios in which this happens. For example, traffic in the original direction hits the firewall on port1, and is routed to port2. However, returning traffic is received on port3 instead. In this scenario, asymmetric routing occurs and the returning traffic is blocked.

If for some specific reason it is required that a FortiGate unit should permit asymmetric routing, you can configure it by using CLI commands per VDOM.

To configure asymmetric routing per VDOM by using the CLI:

# config vdom

edit <vdom_name>

config system settings

set asymroute enable

end

next

end

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.