FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Biraman
Staff
Staff
Article Id 254529
Description This article describes a scenario where an attempt is being made to steer internet traffic using SD-WAN rules when a mix of static and dynamic default routes is in use.
Scope FortiGate.
Solution

In some network topologies, FortiGate has been set up with more than one default route for redundancy and one of the internet links uses dynamic routing to push the default route while another is connected using the static default links. In cases like these, it becomes challenging to utilize both ISP links.

Note: FortiOS will always prefer a static route of the same prefix length over a dynamic route, even if the AD is the same.


Top.JPG


In this example, BGP is already configured and receiving a default route from the neighbor.

Static route configuration on the FortiGate side:

 

# config router static
    edit 3

        set gateway 10.21.137.1

        set distance 20 <-- Same AD as EBGP

        set device "port1"

    next

end

 

BGP receiving default route:

 

# get router info bgp neighbors 10.10.50.2 received-routes

VRF 0 BGP table version is 4, local router ID is 10.21.137.214

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

 

   Network          Next Hop            Metric     LocPrf Weight RouteTag Path

*> 0.0.0.0/0        10.10.50.2                             0        0 6502 6501 6500 ? <-/->

 

The active routing table only shows the static route but no BGP default route:

 

# get router info routing-table  details

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

       V - BGP VPNv4

       * - candidate default

 

Routing table for VRF=0

S*      0.0.0.0/0 [20/0] via 10.21.137.1, port1, [1/0]

C       10.10.50.0/24 is directly connected, port2

C       10.10.60.0/24 is directly connected, port3

C       10.21.137.0/24 is directly connected, port1

 

The solution here is to remove the current static default route of 0.0.0.0/0 and instead add two static routes which cover all routes and have different prefix length. 0.0.0.0/1 and 128.0.0.0/1 can be used here as two routes which will allow the default route 0.0.0.0/0 pushed by the BGP peer to be added in the active routing table, as the static and dynamic default routes now have a different prefix length.

 

# config router static

    edit 1

        set dst 128.0.0.0 128.0.0.0

        set gateway 10.21.137.1

        set distance 20

        set device "port1"

    next

    edit 2

        set dst 0.0.0.0 128.0.0.0

        set gateway 10.21.137.1

        set distance 20

        set device "port1"

    next
    edit 3

        set status disable <- Default static route for 0.0.0.0/0 is disabled

        set gateway 10.21.137.1

        set distance 20

        set device "port1"

    next
end

 

Note:

Either disable the route for 0.0.0.0/0 or delete it, but maintain local or independent access to FortiGate to avoid being locked out from the device.

The following is the active routing table after adjusting the routes' prefix lengths. Both the BGP and static routes now co-exist in the active routing table:

 

# get router info routing-table details

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

       V - BGP VPNv4

       * - candidate default

 

Routing table for VRF=0

B*      0.0.0.0/0 [20/0] via 10.10.50.2 (recursive is directly connected, port2), 04:16:21, [1/0]   
S       0.0.0.0/1 [20/0] via 10.21.137.1, port1, [1/0]             

C       10.10.50.0/24 is directly connected, port2

C       10.10.60.0/24 is directly connected, port3

C       10.21.137.0/24 is directly connected, port1

S       128.0.0.0/1 [20/0] via 10.21.137.1, port1, [1/0]

 

Now, SD-WAN rules can be used to steer the traffic for PC1 through BGP ISP and PC2 through the static route ISP:


SD.JPG

Results Verification – The packet capture showing traffic coming from 10.10.60.3 (PC1) is going out through Port1 (BGP) and traffic from 10.10.60.6 (PC2) is going via Port2 (Static). (Packets have source NAT applied while leaving, which means a different source IP will be seen when traffic leaves the interface)

 

# dia sniffer packet any "host 8.8.8.8 and icmp" 4 0 l
Using Original Sniffing Mode
interfaces=[any]
filters=[host 8.8.8.8 and icmp]
2023-04-28 15:31:07.138411 port3 in 10.10.60.3 -> 8.8.8.8: icmp: echo request
2023-04-28 15:31:07.138461 port1 out 10.21.137.214 -> 8.8.8.8: icmp: echo request
2023-04-28 15:31:07.138806 port1 in 8.8.8.8 -> 10.21.137.214: icmp: echo reply
2023-04-28 15:31:07.138819 port3 out 8.8.8.8 -> 10.10.60.3: icmp: echo reply
2023-04-28 15:31:14.254192 port3 in 10.10.60.6 -> 8.8.8.8: icmp: echo request
2023-04-28 15:31:14.254590 port2 out 10.10.50.1 -> 8.8.8.8: icmp: echo request
2023-04-28 15:31:14.255707 port2 in 8.8.8.8 -> 10.10.50.1: icmp: echo reply
2023-04-28 15:31:14.255729 port3 out 8.8.8.8 -> 10.10.60.6: icmp: echo reply
^C
8 packets received by filter
0 packets dropped by kernel