Technical Tip: BGP dual-home example - solution to avoid RPF problem in asymetric routing scenario

rmetzger · ‎08-26-2009

Description

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 the 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, neither on the Customer side nor on the 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 were used, all traffic would return to the original egress interface without asymmetric routing.

Scope

All FortiGate running in NAT and VDOM mode.

Solution

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 replies 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 is dedicating a 'routing' VDOM on which asymmetric routing will be enabled.

Let's assume 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.

There is now 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 there is 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...