Help
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.
Elvio_Corte
Staff
Staff

Created on ‎08-21-2024 07:57 AM Edited on ‎02-20-2025 07:49 AM By Moderator

Article Id 335180

Troubleshooting Tip: VRF routing behavior when setting up management interface for administrative access

Description

This article describes VRF routing behavior when setting up a management interface in VRF 0 for administrative access.
Scope

FortiGate v7.4.0.
Solution
VRF 0 is a special VRF. By default, all routing is done in VRF 0. Therefore all routes in different VRFs, such as VRF 1 or VRF 2, will all be included in VRF 0. VRF 0 cannot be used in a cross-VRF scenario.
 
For the rest of the VRFs, the routes relating to that VRF are isolated from other VRFs. Interfaces in one VRF cannot reach interfaces in a different VRF. Except for VRF 0, if the FortiGate is using a dedicated mgmt interface and it is assigned to VRF=0, local-in, and local-out traffic will perform a Routing Lookup based on the Routing Information from ALL VRFs in the device.
 
If the above statements are not fully understood, issues may be faced when getting administrative access to the device via the management interface.
 
Imagine the following scenario:
 
config system interface
    edit "mgmt1"
        set vdom "root"
        set vrf 0 -> DEFAULT VRF
        set ip 10.10.10.1 255.255.255.0
        set allowaccess ping https ssh fabric
        set type physical
        set alias "MGMT"
        set role lan       
    next
    edit "OUTSIDE"
     set vdom "root"
     set vrf 1
     set ip 172.16.10.1 255.255.255.240
     set allowaccess ping
     set role lan
     set interface "port1"
     set vlanid 10
    next
    edit "INSIDE"
        set vdom "root"
        set vrf 1
        set ip 172.16.40.1 255.255.255.240
        set allowaccess ping https ssh http
        set role lan
        set interface "port32"
        set vlanid 40
    next
end
 
get router info routing-table  all 
    ...omit
Routing table for VRF=0
S*      0.0.0.0/0 [10/0] via 10.10.10.2, mgmt1, [1/0]
C       10.10.10.0/24 is directly connected, mgmt1
 
Routing table for VRF=1
S*      0.0.0.0/0 [10/0] via 172.16.10.2, OUTSIDE, [1/0]
C       172.16.10.0/28 is directly connected, OUTSIDE
C       172.16.40.0/28 is directly connected, INSIDE
S       10.0.0.0/8 [10/0] via 172.16.40.2, INSIDE, [1/0]
S       172.16.0.0/16 [10/0] via 172.16.40.2, INSIDE, [1/0]
S       192.168.0.0/16 [10/0] via 172.16.40.2, INSIDE, [1/0]
 
If the workstation has an IP address in the same subnet as interface mgmt1, for example 10.10.10.50/24. It is expected to receive the traffic through mgmt1 as INBOUND. The traffic is considered as local-in traffic because the destination is the FortiGate. In this case is an attempt to connect to the GUI. 
 
mgmt1 in 10.10.10.50.53557 -> 10.10.10.1.443: syn 3625806780 
 
In this scenario, it will not be an issue. Since the FortiGate has a CONNECT route for that network segment.
 
edit "mgmt1"
    set ip 10.10.10.1 255.255.255.0
 
Routing table for VRF=0
C       10.10.10.0/24 is directly connected, mgmt1
 
For example, if an SSH request from the Workstation with IP address 10.10.10.50 to the FortiGate IP address 10.10.10.1.
The IN and OUT are through the mgmt1 interface and it can be seen request-SYN and the reply-SYN/ACK through the same interface mgmt1. There is no asymmetric traffic.
 
mgmt1 in 10.10.10.50.53557 -> 10.10.10.1.22: syn 3625806780 
mgmt1 out 10.10.10.1.22 -> 10.10.10.50.53557: syn 669599337 ack 3625806781 
 
However, trying from a different VLAN for example Workstation with IP 172.16.20.1 will work only for ICMP.
This is because Ping is based on ICMP protocol. It has only a few ICMP types most used are Echo Request and Echo Reply.
ICMP is generally handled by the kernel, so it doesn't check the routing table, and does not perform a Routing lookup.
On the other hand, TCP/UDP traffic checks the routing traffic for the reply.
 
In this example, the IN traffic is through mgmt1, yet the OUT traffic or 'reply' is through the INSIDE interface.
It is an ASYMMETRIC TRAFFIC issue.
 
diag sniffer packet any 'host 10.10.10.1 and port 22' 4 0 l
   ...OMIT
2024-07-22 08:23:05.200537 mgmt1 in 172.16.20.1.53557 -> 10.10.10.1.22: syn 3625806780 
2024-07-22 08:23:05.200562 INSIDE out 10.10.10.1.22 -> 172.16.20.1.53557: syn 669599337 ack 3625806781 
 
The access is via SSH port 22 (same behavior for HTTPS) and will fail due to this asymmetric. It is possible to wonder why the FortiGate replies through interface INSIDE instead of mgmt1 even though it has a default static route in VRF=0 saying that all traffic should be sent through mgmt1.
 
     get router info routing-table  all 
    ...omit
Routing table for VRF=0
S*      0.0.0.0/0 [10/0] via 10.10.10.2, mgmt1, [1/0] -> default route in VRF=0
Routing table forVRF=1
S       172.16.0.0/16 [10/0] via 172.16.40.2, INSIDE, [1/0] -> More specific route in VRF=1
 
This is because the FortiGate considers all possible routes from all VRFs and in this case, there is a better/more specific route to reply. That is via the INSIDE-interface based on a STATIC route on VRF=1.
 
As mentioned previously, VRF 0 is the only one that can reach interfaces in a different VRF. Meaning FortiGate will perform a routing lookup base in ALL ROUTING INFORMATION FROM ALL VRFs to reply traffic that comes in a interface assigned to VRF=0. In this case, there is a much better specific route in VRF=1, it will choose that route.
 
Workaround: However if administrative access is required to access the device from any other private network, and if this interface is only used for this purpose, one solution is to move the management interface to another VRF instead of VRF 0. In this case, moving for example to VRF 2, it will mean that the mgmt1 interface will be isolated from the other VRFs, and administrative access via SSH and HTTPS coming through mgmt1 no matter the source IP will work due to the FortiGate will use his default static route in VRF=2 to reply the traffic.
 
Note: Local traffic across different VRFs should check the routing table when traffic reverses. Therefore interfaces assigned to VRF=0 should be considered all possible routes in all VRFs.
 
Note: On FortiOS v7.2.10 the VRF=0 will not use the routing table of other VRFs. It will perform Routing Lookup base only in the VRF=0. In this case, even if there is a more specific route on another VRF it will not cause asymmetric traffic.
 
port6 in 10.1.7.11.55129 -> 10.1.6.10.443: syn 3768995624
port6 out 10.1.6.10.443 -> 10.1.7.11.55129: syn 895643532 ack 3768995625
 

get route info routing-table details 10.1.7.11

Routing table for VRF=0
Routing entry for 0.0.0.0/0
Known via "static", distance 10, metric 0, best
* vrf 0 10.1.6.11, via port6


Routing table for VRF=1
Routing entry for 10.1.7.0/24
Known via "static", distance 10, metric 0, best
* vrf 1 10.100.1.1, via port1

 
975
Suggest New Article
Article Feedback
Broad. Integrated. Automated.

The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.

Social Media
Security Research
Company
News & Articles
Contact Us

Copyright 2025 Fortinet, Inc. All Rights Reserved.