BGP Over IPsec: Tunnel Up, BGP Up, Half the Subnets Unreachable

BGP originates only what it is told to originate, and only for prefixes that already exist in the RIB.

• 10.60.0.0/16 is directly connected on HQ port4, so HQ can route to it, but no config router network entry and no redistribution covers it. It is therefore never advertised to any neighbour.
• The branch has no BGP path, so its local ISP default route (distance 5 static) carries 10.60.x.x to the internet, where it is dropped. The symptom is a black hole, not a routing loop.

Prove it from the advertisement, not from HQ's routing table

get router info bgp neighbors 169.254.10.2 advertised-routes
get router info bgp summary

On the branch:

get router info routing-table bgp
get router info bgp network

If HQ's RIB has 10.60.0.0/16 but the advertised-routes list for that neighbour does not, the defect is in HQ's BGP export policy. This is the classic misread: a route being present on HQ says nothing about what HQ told the branch.

Option 1 - explicit network statement

config router bgp
    config network
        edit 0
            set prefix 10.60.0.0 255.255.0.0
        next
    end
end

Fast and narrow, but the prefix must match a RIB entry exactly. If the call centre is actually carved into /24s behind an internal router, this statement does nothing; you would list the /24s or use aggregate-address to summarise.

Option 2 - redistribute connected behind a route-map

config router bgp
    config redistribute "connected"
        set status enable
        set route-map "ADVERTISE-DC"
    end
end

Scales, but unguarded redistribution also exports the 169.254.10.x/30 tunnel subnets and every future connected segment to all 14 branches. With overlapping branch LANs that is a loop and black-hole risk. The route-map/prefix-list must permit only the intended blocks.

Choice Option 2 with a tight prefix-list for a 14-branch topology, because the next new HQ segment then needs no BGP change and cannot be forgotten. Pair it with aggregate-address so branches carry one summary rather than dozens of prefixes.

Applying it Clear or soft-reset the neighbour - execute router clear bgp ip <neighbour> is disruptive and resets the session - then confirm on branch 7 with get router info routing-table bgp and a diagnose debug flow trace showing traffic leaving via the tunnel interface rather than wan1.

Check in this order, because each layer can mask the next.

1. IPsec selectors - diagnose vpn tunnel list name <tunnel> shows the phase 2 selectors. If the tunnel was built with specific local subnets, 10.20.30.0/24 is not inside the selector and HQ's packets are dropped before routing matters. Route-based tunnels with 0.0.0.0/0 selectors avoid the issue entirely; specific selectors must be updated whenever a VLAN is added.
2. Routing both ways - the branch must advertise 10.20.30.0/24 (network statement or redistribution) and HQ must have a route to it via the tunnel interface. A one-way advertisement gives the usual half-open behaviour: branch to HQ works, HQ to branch does not.
3. Firewall policy and NAT - HQ's tunnel policy address objects and the branch's inbound policy must both include the new subnet. The most common ordering error is a branch policy for 10.20.30.0/24 that sits below the internet-facing policy, so the new VLAN's traffic is source-NATed out the ISP instead of entering the tunnel.

Diagnostic shortcut On the branch, diagnose debug flow filtered on a source address in 10.20.30.0/24 shows the policy ID and egress interface. If it shows wan1, the problem is policy order, not BGP or selectors. If nothing appears at all, the traffic is not reaching the FortiGate and the VLAN/gateway is the first thing to check.