Technical Tip: Using Blackhole routes in site-to-site IPsec VPN

Description

Solution

In this example, a site-to-site VPN between two FortiGate devices is already configured and working.

When the tunnel is up, BR-FGT sends private network traffic with destination addresses in the 10.0.0.0/8 range across the VPN tunnel.

BR-FGT # diagnose sniffer packet HQ1-BR1 'host 10.45.66.100' 4 0 l
interfaces=[HQ1-BR1]
filters=[host 10.45.66.100]
pcap_lookupnet: HQ1-BR1: no IPv4 address assigned
2026-03-06 22:09:57.777963 HQ1-BR1 -- 192.168.33.50 -> 10.45.66.100: icmp: echo request
2026-03-06 22:09:57.778224 HQ1-BR1 -- 10.45.66.100 -> 192.168.33.50: icmp: echo reply
2026-03-06 22:09:58.788626 HQ1-BR1 -- 192.168.33.50 -> 10.45.66.100: icmp: echo request
2026-03-06 22:09:58.788791 HQ1-BR1 -- 10.45.66.100 -> 192.168.33.50: icmp: echo reply
...

There are two cases to consider for tunnel failure:

1. Traffic behavior when the VPN tunnel is down:

For example, an endpoint at the BR-FGT site initiates a ping (ICMP echo request) for an IP address at the HQ-FGT site. The request reaches BR-FGT, and the firewall performs a route lookup. As the tunnel is down, route lookup matches the default route, and the packet is sent using wan1.

BR-FGT # get router info routing-table details 10.45.66.100

Routing table for VRF=0
Routing entry for 10.0.0.0/8
Known via "static", distance 10, metric 0
via HQ1-BR1 tunnel 192.0.2.1 vrf 0 inactive, tun_id

Best selected route:
Routing entry for 0.0.0.0/0
Known via "static", distance 1, metric 0, best
* vrf 0 192.0.2.1, via wan1, origin 2

BR-FGT # diagnose sniffer packet wan1 'host 10.45.66.100' 4 0 l
interfaces=[wan1]
filters=[host 10.45.66.100]
2026-03-06 22:17:12.173775 wan1 -- 192.0.2.2 -> 10.45.66.100: icmp: echo request
2026-03-06 22:17:13.198616 wan1 -- 192.0.2.2 -> 10.45.66.100: icmp: echo request

Generally, the ISP will drop the packet as the remote host is a private IP address.

Impact: sensitive private traffic may be sent unencrypted over WAN interfaces when the VPN tunnel is down.

2. Traffic behavior for stale connectionless sessions when the VPN tunnel comes back up after failure:

Connectionless protocols include UDP and ICMP (ping). If a session was present during the tunnel failure, subsequent traffic for the same IP addresses with the same source/destination port or ICMP identifier hits the same session on the FortiGate and uses the same route in the route cache.

FortiGate will maintain a session with no observed traffic for a specific time (based on the session-TTL) before removing the session. By default, the session-TTL for the ICMP is 1 minute. If matching traffic is seen within the session-ttl time, the request hits the same session, and the timer resets.

Impact: connectionless private traffic, such as ping, DNS, and syslog, may remain in a non-working state even after the tunnel is up.

Workaround: Clear the affected stale sessions. Refer to this article to clear particular sessions using filters: Technical Tip: Using filters to clear sessions on a FortiGate.

Resolution:

In either scenario, the method to prevent the negative impact is the same: configure a blackhole route with a higher Administrative Distance and the prefix length the same or smaller than existing routes handling VPN tunnel traffic.

BR-FGT # get router info routing-table details 10.45.66.100

Routing table for VRF=0
Routing entry for 10.0.0.0/8
Known via "static", distance 10, metric 0, best
* via HQ1-BR1 tunnel 192.0.2.1 vrf 0, tun_id

Warning: 'set distance 255' is configurable, but Administrative Distance 255 should not be used for blackhole routes or any route intended to be active. Routes with this distance are never installed in the routing table.

The black hole route is active when the tunnel is down. When the route is active, the FortiGate silently drops traffic for matching destinations and does not create a session in the session table. This allows future traffic to pass immediately when the VPN tunnel recovers and prevents private traffic from leaking onto the WAN while the tunnel is down.

• If a site-to-site VPN was configured using the IPsec Wizard, the blackhole route will be created automatically with an administrative distance of 254.
  
• Each FortiGate platform has a maximum number of static routes that can be created. The maximum can be verified by searching this document, Maximum Value Table for the entry 'router.static'.
• To conserve the number of available static routes, it is possible to put all remote subnets of IPsec tunnels in a single address group and create only one black hole route.
  
  

  

To use an address object in routing configuration, go to Policy & Objects -> Addresses and ensure 'Static route configuration' or 'Routing Configuration' is enabled for the addresses and address group.

• 254 is the recommended Administrative Distance value for blackhole routes. Configuring a lower value may cause unintended blackhole route matches and dropped traffic.