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.
rmetzger
Staff
Staff

Purpose

This article describes a solution for a FortiGate dual-home connected in BGP to an ISP, and receiving its default route in BGP from this ISP.
This example shows how to workaround an asymmetric routing problem due to the Fortigate dropping traffic because of RPF check ( see more information about RPF in the related article at the end of this page).
 
The solution presented here is based on a dedicated routing VDOM with asymmetric routing enabled, also sometimes called "gatekeeper" VDOM. It presents the advantage of not having to change any BGP settings, nor on Customer side, neither on ISP side, while keeping all Firewall and RPF functions active on the sub-VDOM(s).

Note that other solutions will exist, based on Local Preference setting on the ISP side, or MED, but this will require an interaction and some agreement with the ISP.

It is also assumed that the traffic to be routed between the dmz and the ISP is not subject to NAT ( Firewall Policies with NAT disabled) ; If NAT was used, all traffic would return to the original egress interface without asymmetric routing.


Scope
All FortiGate running in NAT and VDOM mode
Diagram

The base scenario with asymmetric routing is the following :
 
rmetzger_FD30895_1.JPG
 
 
The green arrows show the traffic flow from 172.16.1.254 to 172.16.2.254. At step 5, the return traffic is ingressing on wan2, but the FGT-Customer has got no default route (or simply no specific route) to 172.16.2.254 via wan2, and will therefore drop the traffic due to RPF (reverse past forwarding) check.
 
See the current routing table of FGT-Customer  :
 
FGT-Customer # get router info routing-table all
B*      0.0.0.0/0 [20/0] via 10.1.1.101, wan1, 00:25:03
C       10.1.1.0/24 is directly connected, wan1
C       10.2.2.0/24 is directly connected, wan2
C       10.160.0.0/23 is directly connected, internal
C       172.16.1.0/24 is directly connected, dmz
 
 
And the echo reply ingressing wan2 but not forwarded to the source on dmz :
 
FGT-Customer # diagnose  sniffer packet  any "host 172.16.2.254" 4
1.612126 dmz in 172.16.1.254 -> 172.16.2.254: icmp: echo request
1.612170 wan1 out 172.16.1.254 -> 172.16.2.254: icmp: echo request
1.615987 wan2 in 172.16.2.254 -> 172.16.1.254: icmp: echo reply
2.616253 dmz in 172.16.1.254 -> 172.16.2.254: icmp: echo request
2.616317 wan1 out 172.16.1.254 -> 172.16.2.254: icmp: echo request
2.616987 wan2 in 172.16.2.254 -> 172.16.1.254: icmp: echo reply


Expectations, Requirements

The traffic should be routed back regardless if the default route is pointing to router1 or router2.


Configuration

One solution presented here consists in dedicating a "routing" VDOM on which asymmetric routing will be enabled.
Let's assume that this VDOM will be the default "root" VDOM, and the VDOM to the internal or user traffic will be named VDOM_Users.

Both VDOMs are interconnected via an unnumbered inter-VDOM link.
The final configuration of FGT_Customer is attached to this article.
 
We now have the following diagram in VDOM mode  :
 
 rmetzger_FD30895_2.JPG
 
This is the new global setting for the interfaces :
 
config system interface

    edit "wan1"
        set vdom "root"
        set ip 10.1.1.100 255.255.255.0
        set allowaccess ping https ssh http telnet
        set type physical
    next

    edit "wan2"
        set vdom "root"
        set ip 10.2.2.200 255.255.255.0
        set allowaccess ping
        set type physical
    next

    edit "dmz"
        set vdom "VDOM_Users"
        set ip 172.16.1.1 255.255.255.0
        set allowaccess ping https ssh http telnet
        set type physical
    next

    edit "internal"
        set vdom "VDOM_Users"
        set ip 10.160.1.26 255.255.254.0
        set allowaccess ping https ssh snmp http telnet
        set type physical
        set alias "Management"
    next

    edit "VDOM_link0"
        set vdom "root"
        set type vdom-link
    next

    edit "VDOM_link1"
        set vdom "VDOM_Users"
        set type vdom-link
    next

end
 
 
This is the new configuration specific to the "root" VDOM :
 
config system settings
    set asymroute enable
end
 
config router static
    edit 1
        set device "VDOM_link0"
        set dst 172.16.1.0 255.255.255.0
        set weight 50
    next
end

config firewall policy
    edit 1
        set srcintf "VDOM_link0"
        set dstintf "wan1"
            set srcaddr "all"
            set dstaddr "all"
        set action accept
        set schedule "always"
            set service "ANY"
    next
    edit 2
        set srcintf "VDOM_link0"
        set dstintf "wan2"
            set srcaddr "all"
            set dstaddr "all"
        set action accept
        set schedule "always"
            set service "ANY"
    next
end
 
 
This is the new configuration specific to the "VDOM_Users " VDOM :
 
config router static
    edit 1
        set device "VDOM_link1"
        set weight 50
    next
end

config firewall policy
    edit 1
        set srcintf "dmz"
        set dstintf "VDOM_link1"
            set srcaddr "all"
            set dstaddr "all"
        set action accept
        set schedule "always"
            set service "ANY"
    next
end
 
 
 


Verification

Verification with the default route pointing to router1 on the VDOM "root" :
 
FGT-Customer (root) # get router info routing-table all
B*      0.0.0.0/0 [20/0] via 10.1.1.101, wan1, 00:03:27
C       10.1.1.0/24 is directly connected, wan1
C       10.2.2.0/24 is directly connected, wan2
S       172.16.1.0/24 [10/0] is directly connected, VDOM_link0, [0/50]
 
 
And we see now the echo reply ingressing wan2 and  forwarded to the source on the dmz :
 
FGT-Customer (root) # diagnose sniffer packet any "host 172.16.2.254" 4
0.641377 dmz in 172.16.1.254 -> 172.16.2.254: icmp: echo request
0.641377 VDOM_link0 in 172.16.1.254 -> 172.16.2.254: icmp: echo request
0.641493 wan1 out 172.16.1.254 -> 172.16.2.254: icmp: echo request
0.642139 wan2 in 172.16.2.254 -> 172.16.1.254: icmp: echo reply
0.642139 VDOM_link1 in 172.16.2.254 -> 172.16.1.254: icmp: echo reply
0.642203 dmz out 172.16.2.254 -> 172.16.1.254: icmp: echo reply

 

Related Articles

Technical Note: Details about FortiOS RPF (Reverse Path Forwarding), also called Anti-Spoofing

Technical Note: Static NAT VIP accessible from 2 external interfaces with E-BGP peerings (dual-homin...

Contributors