How to Tell a Routing Loop From Route Flapping on VPN Sites
A routing loop and a flapping route cause the same intermittent loss. Three checks on the gateways tell them apart before you change anything.
Two sites, one tunnel, and a remote prefix that answers for a while and then goes silent. The reflex is to call it a routing loop, and sometimes that is exactly what it is. But a loop and a flapping route produce the same complaint, and they need opposite repairs: one is a forwarding decision that never terminates, the other is a prefix that keeps leaving the table. Three observations separate them, and you can collect all three from the gateway CLI before you touch a filter or restart a tunnel.
A loop is decided hop by hop. Site A selects B as the next hop for the destination, B selects A for the same destination, and the packet expires on TTL after two round trips. A flap is decided by the routing protocol instead: the prefix is withdrawn, reinstalled, or replaced by an alternate next hop, so some packets have no route at all while others follow a perfectly good one.
The three checks that settle the question
You do not need a packet capture to make the first call. You need the prefix state on both ends, the next hop each side selects, and a hop count that either repeats or does not. If the prefix stays installed with the same next hop while traffic is failing, the loop lives in the forwarding path. If the prefix vanishes and returns, the fault is upstream of forwarding and the fix belongs in the routing protocol, not in a static route.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
One warning before you start. If you are reading this over the tunnel that is looping, your session dies the moment you change the route. Open a console or a management path that does not depend on the prefix you are about to repair.
Check one: is the prefix stable or churning
Ask the kernel what it installed, not what the configuration file promises. On a Linux gateway, ip route get 10.20.30.40 runs the same lookup the forwarding path runs, including policy tables, while ip route show 10.20.30.0/24 shows the entry itself. ip monitor route streams every change as it happens, which is the fastest way to watch a prefix arrive and leave.
On a router running FRR or BIRD, the forwarding table is not the interesting one. show ip bgp 10.20.30.0/24 returns the selected path and its uptime; an uptime that keeps resetting every few minutes is a flap you can name, not a loop. show ip bgp summary shows neighbor state and prefix counts, so a peer that keeps dropping takes the blame off the forwarding path.
Write the answer down before you change anything. Stable for ten minutes while pings failed, and disappeared four times in ten minutes, lead to different next steps. The second one makes every static-route theory irrelevant.
Check two: does the next hop point back into the arrival tunnel
A loop needs two gateways to agree. On the site that receives the packet, look at the route the packet will use to leave: ip route get 10.20.30.40 from 10.10.5.20 with the real source address, because a policy rule may answer differently from the main table. Then repeat the lookup on the site that sent it. If each side selects the other as the next hop for the same prefix, the loop is proven and no capture will add anything.
The cause is almost always an advertisement that should not have crossed the tunnel. A default route redistributed into the tunnel, an aggregate that covers the remote site's own subnet, or a static route pointing at the peer just in case all create the same mutual next hop. The tunnel can be fully established and still carry traffic in a circle; strongSwan's forwarding notes describe the routing side of that requirement.
WireGuard deserves its own note, because there is no advertisement to blame. wg show lists the AllowedIPs for each peer, and the kernel accepts a destination for a peer only if it falls inside that range. A loop there is an overlapping AllowedIPs range or a static route pointing back across the interface, so the fix lives in those two places and nowhere else.
Check three: read the hop count, not the stars
traceroute -n -I 10.20.30.40 and mtr -n -r -c 20 10.20.30.40 both show the path, and ICMP mode often survives filtering that eats UDP probes. A loop looks like a short repeating sequence of the same two gateway addresses with the TTL climbing each time. A drop looks like stars after the last gateway that answered, and a single silent hop is not evidence of anything.
When the path is ambiguous, read the TTL on the wire. tcpdump -ni any -vv icmp on both gateways shows the TTL of each packet and the source address of every time-exceeded reply. If a packet reaches the far site with a TTL lower than the number of hops the path can contain, something is adding hops that traceroute is not showing you, which happens when one site's firewall answers probes on behalf of another.
Repair the prefix's owner, then verify both directions
Decide which site originates the destination and which transit paths are allowed, then change the advertisement or the static route at that owner. Correcting the receiving site is tempting and usually wrong: it hides the loop for one prefix and leaves the bad advertisement in place for the next one. Route tags, distribute lists, and split-horizon rules exist to stop this at the source, and they are cheaper than a filter that matches a single prefix.
After the change, verify forward and return separately, because a loop can be replaced by a black hole without any visible improvement in the symptom. Run ip route get from both ends, send traffic from a host that is not the gateway, and leave ip monitor route running for at least one hold timer so a flap is not mistaken for a fix.
Before you change anything, confirm these five points: the prefix is stable or churning, the next hop on both ends points at a tunnel, the hop count repeats or does not, one site owns the prefix, and you hold a management path that survives the change. If any one of the five is unknown, the other four are guesses.