Troubleshooting Tip: Common Issue in Hub-and-Spoke dual IPsec VPNs using BGP

Description

This article describes a common configuration error in a hub-and-spoke topology using dual IPsec VPNs with BGP.

Scope

FortiGate.

Solution

This article assumes the following topology is in place:

The following assumptions are also made:

• IPsec - green link.

• IPsec2 - purple link.

• IPsec Hub interface: 10.100.1.1/28

• IPsec Spoke1 interface: 10.100.1.2/28

• IPsec Spoke2 interface: 10.100.1.3/28

• IPsec2 Hub interface: 10.100.2.1/28

• IPsec2 Spoke1 interface: 10.100.2.2/28

• IPsec2 Spoke2 interface: 10.100.2.3/28

• LAN behind Spoke1: 10.1.2.0/24

The HUB assigns the IP addresses to the IPsec interfaces on the Spokes dynamically from an IP range.

config vpn ipsec phase1-interface
    edit "IPsec1"
        set mode-cfg enable
        set ipv4-start-ip 10.100.1.2
        set ipv4-end-ip 10.100.1.15
    next
    edit "IPsec2"
        set mode-cfg enable
        set ipv4-start-ip 10.100.2.2
        set ipv4-end-ip 10.100.2.15
    next
end

The Hub FortiGate learns the Spoke1 subnet 10.1.2.0/24 as presented in the following output:

Hub# get router info routing-table all:

B 10.1.2.0/24 [200/0] via 10.100.1.2 (recursive is directly connected, IPsec1), 5d10h01m, [1/0]
              [200/0] via 10.100.2.2 (recursive via wan1), 5d10h01

Note: Normally, the wan1 should not be shown as the exit interface, as the FortiGate should not send internal traffic (with a private IP address as destination) on the WAN interfaces.

The wan1 could be present in cases where IPsec2 tunnel goes down.

That happens because when Spoke1 advertises its local routes to the Hub, the Hub will advertise them to the Spoke2 and the next hop is the interface's IPs on Spoke1 (10.100.1.2/28 and 10.100.2.2/28). Since they are on the same subnet, it is shown as directly connected for the IPsec interface.

The IPsec2 tunnel is now down and so, to reach the the next-hop 10.100.2.2, the FortiGate recursively checks the routing table and matches the default route 0.0.0.0/0 with the exit interface wan1.

In order to avoid this behavior, is mandatory to set 'set next-hop-self-rr enable' on the HUB BGP configuration, since the HUB will be the route reflector. This way, the HUB will change the next-hop to itself before re-advertising the routes.

In this case, if the IPsec2 is down, the next hop will be only 10.100.1.1 (HUB IP) and so will be reachable through the IPsec tunnel.

If neighbor groups are configured, run the following commands to correctly set up this command:

config neighbor-group
    edit IPSEC1
        set interface "VPN_IPSEC1"
        set next-hop-self-rr enable
    next
    edit IPSEC2
        set interface "VPN_IPSEC2"
        set next-hop-self-rr enable
    next
end

With this change applied, the routing table should be similar to the following when all of the IPsec tunnels are UP:

B          10.1.2.0/24 [200/0] via 10.100.1.1 (recursive is directly connected, IPSEC), 5d3h1m, [1/0]
                       [200/0] via 10.100.1.1 (recursive is directly connected, IPSEC2), 5d3h1m, [1/0]
                       [200/0] via 10.100.2.1 (recursive is directly connected, IPSEC), 5d3h1m, [1/0]
                       [200/0] via 10.100.2.1 (recursive is directly connected, IPSEC2), 5d3h1m, [1/0]

Note: Only relevant parts of the outputs and configurations are shown in this article.

Related articles:

• Technical Tip: Explanation of 'set next-hop-self-rr enable'

• IKE Mode Config clients