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.
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 :
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 :
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
