Skip to main content
Matt_B
Staff & Editor
Staff & Editor
June 11, 2025

Technical Tip: FortiOS responds to VRF 0 local traffic using a different VRF

  • June 11, 2025
  • 0 replies
  • 1148 views
Description This article describes the expected FortiOS behavior when management traffic is received on VRF 0.
Scope FortiGate v7.4.1 and later.
Solution

After upgrading to v7.4.1 or later, FortiOS may respond to management traffic received on VRF 0 using a different VRF and different interface, if a more specific route exists in a different VRF. This can cause the firewall to not be accessible using HTTPS and SSH after the upgrade.

 

VRF 0 is a special VRF that includes routes from multiple VRFs. See this document: Virtual routing and forwarding.

 

After the upgrade, the most specific route is used to forward replies received in VRF 0 if the most specific route is in a different VRF.

 

Example configuration:

 

config system interface

    edit "port1"

        set vdom "root"

        set vrf 0 <-- Default configuration.

        set ip 10.255.4.31 255.255.252.0

        set allowaccess ping https ssh

    next

end

 

Routing Table:

 

get router info routing-table all

 

Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via 10.255.7.254, port1, [1/0]
C 10.255.4.0/22 is directly connected, port1

 

Routing table for VRF=2
S* 0.0.0.0/0 [10/0] via 10.255.11.254, port1.0003, [1/0]
S 10.0.0.0/8 [10/0] via 10.255.11.254, port1.0003, [1/0]
C 10.255.8.0/22 is directly connected, port1.0003

 

Packet sniffer showing different interfaces used to forward replies:


FortiGate-A # diagnose sniffer packet any 'port 22' 4 1000 l
interfaces=[any]
filters=[port 22]
2025-05-26 12:33:15.822250 port1 in 10.254.200.200.50937 -> 10.255.4.31.22: syn 4106311737
2025-05-26 12:33:15.822283 port1.0003 out 10.255.4.31.22 -> 10.254.200.200.50937: syn 1240260999 ack 4106311738

 

Because the most specific route to the IP address 10.254.200.200 is via port1.0003, this interface is used to forward replies for management traffic, causing asymmetric routing and possible packet loss.

 

Workarounds:

  • Identify which route in the other VRF is unexpectedly matching the traffic, and create a static route with the same prefix length and the intended exit VRF 0 interface. The route could be any administrative distance and priority.

  • Change the interface VRF to a non-zero value during a maintenance window following this document: Implementing VRF. It is strongly recommended to review the change beforehand to ensure that other traffic will not be affected.

config router static

    edit <index>

        set dst 10.0.0.0 255.0.0.0

        set gateway 10.255.7.254
        set device port1

    next

end

 

  • Use a dedicated VDOM for management, see VDOM overview. Each VDOM maintains an independent routing table.
  • If an HA reserved management interface is configured, the reserved management interface has a dedicated hidden VDOM and is not affected. See this article: Technical Tip: HA Reserved Management Interface.

 

Note: The issue above is not present in v7.4.11, but may occur if the more specific route via another VRF is a 'blackhole' route.

 

Example:

config router static
    edit <index>
        set dst 10.0.0.0 255.255.255.0
        set blackhole enable
        set vrf 2
    next
end