Troubleshooting Tip: Traffic originated from hub VTI doesn't reach the spoke FortiGate in a dial-up hub-and-spoke topology

In certain scenarios and deployment types, especially in hub and spoke architectures, there may be a requirement for bidirectional traffic on the virtual tunnel interface (VTI) between the hub and its connected spokes.
This is useful when implementing VXLAN over IPsec, where the virtual tunnel interface is used for VXLAN traffic instead of a loopback interface.

In a standard site-to-site IPsec connection, once the local IP and remote IP are configured under the virtual tunnel interface (VTI), two static routes are automatically added to the routing table for the configured subnet, pointing out through the VPN interface.

The same applies to a hub-and-spoke topology, however in this type of deployment, the IPsec configuration on the hub is set up as dial-up rather than static. All spokes connect to the hub, and if mode-cfg is not configured, which automatically assign IP addresses to the spokes, the VTI IP addresses must be manually configured on both sides.

Traffic generated from the spoke tunnel interface reaches the hub tunnel interface without issues, as the return traffic from the hub exits through the same interface on which it was received. However, when traffic is initiated from the hub tunnel interface toward the spoke tunnel interface, the traffic leaves the hub but never reaches the spoke.

This behavior can break the rare scenarios in which VXLAN needs to be implemented in this type of topology. The reason for this behavior is that when spokes connect to the hub, sub-interfaces are created under the main IPsec interface for each spoke. However, when the local IP and remote IP are configured on the hub's VTI, a static route is automatically added that points to the main IPsec interface rather than the individual sub-interfaces.

This results in incorrect interface selection, causing traffic generated from the hub to exit through the main tunnel interface instead of the appropriate spoke-specific sub-interface.

To resolve this issue, the remote IP on the hub's VTI must be set to 0.0.0.0/0, which prevents the automatic addition of a static route for the subnet pointing out of the VPN interface.
In addition, the /32 IP configured on each spoke's virtual tunnel interface must be advertised via BGP, allowing the hub to learn the correct /32 subnet for each spoke through the appropriate sub-interface.

Hub VTI configuration:

config system interface

    edit "hub"

        set vdom "root"

        set ip 10.10.1.1 255.255.255.255

        set allowaccess ping

        set type tunnel

        set remote-ip 0.0.0.0/0

        set interface "wan1"

    next

end

Spoke VTI configuration:

config system interface

    edit "spoke"

        set vdom "root"

        set ip 10.10.1.2 255.255.255.255

        set allowaccess ping

        set type tunnel

        set remote-ip 10.10.1.254 255.255.255.0

        set interface "wan1"

    next

end

BGP configuration to advertise the Spoke VTI subnet to the hub:

config router bgp

    set as 65412

    config neighbor

        edit "x.x.x.x"

            set remote-as 65412

        next

    end

    config network

        edit 1

            set prefix 10.10.1.2 255.255.255.255

        next

    end

end

Note: In this scenario, it is assumed that BGP is configured using loopback interfaces.

Related article:

Technical Tip: ADVPN with BGP as the routing protocol