Scribd
Upload
925 views2 pages

Use of Black Hole Route in Site To Site IPsec VPN Scenarios

This technical note discusses how to handle routing when an IPsec VPN tunnel goes down between two FortiGate devices. When the tunnel is down, traffic is routed through the default route instead of being dropped. To address this, a black hole route can be configured on the FortiGate for the remote network with a higher distance. This prevents sessions from being created when the tunnel is down, so ping requests return immediately when the tunnel comes back up. The black hole route also improves security by not sending traffic to the default route (ISP) when the tunnel is unavailable.

Uploaded by

Toufik Ablaoui
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
925 views2 pages

Use of Black Hole Route in Site To Site IPsec VPN Scenarios

This technical note discusses how to handle routing when an IPsec VPN tunnel goes down between two FortiGate devices. When the tunnel is down, traffic is routed through the default route instead of being dropped. To address this, a black hole route can be configured on the FortiGate for the remote network with a higher distance. This prevents sessions from being created when the tunnel is down, so ping requests return immediately when the tunnel comes back up. The black hole route also improves security by not sending traffic to the default route (ISP) when the tunnel is unavailable.

Uploaded by

Toufik Ablaoui
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Technical Note: Use of Black hole route in site to site IPsec VPN Print Article

scenarios

Products
FortiGate

Description

This article explains what happens to the traffic when the VPN tunnel goes down with respect
to the routing on the FortiGate.

Solution

In this scenario, it is assumed that there is a site to site VPN between two FortiGate devices
already configured and working.

There are two cases to consider:

1) When VPN tunnel is down.


2) When VPN tunnel comes back up.

- Usually, when the tunnel is up, the traffic between the two sites happens across the VPN
tunnel.

Case 1: When the Tunnel is brought down:

- Using ping to test the traffic.

On Site A, ping is initiated from a PC.


- Request reaches the FortiGate.
- On the FortiGate, route look up is done. As the tunnel is down, the request is not sent out
through the IPsec tunnel, however the default route is chosen and sent out.
- ISP drops it as the remote host is a private IP.

Case 2: When the Tunnel is up:

- If there is a continuous ping request, it hits the same session on the FortiGate and uses the
same route in the route cache.

- Because of the initial request, there is a session created on the FortiGate and will hold that
session for specific time (based on the session-ttl).
- By default, the session-ttl for the ICMP is 1 minute.
- So, if the ping request is re-initiated within this session-ttl time (1 min), the request hits
the same session and will never be able to reach the actual destination.

Session can be cleared in this case or wait for the idle timeout to expire.

The solution to avoid such a situation to occur is as follows:

- On a working site to site VPN configuration, there should be already a static route created
for the remote destination.
- Now, create a black hole route on the FortiGate for the same destination network with
higher distance than the original one (by default it takes the distance '10').

Syntax for the black hole route:

config router static


edit {sequence_number>
set blackhole enable
set distance 50
set dst [destination-address_ipv4mask>
end

This route is active when the tunnel is down. By adding this route the FortiGate is being told
to drop the requests silently.
- So, there are no sessions added on the FortiGate and hence the ping test or the actual
traffic or probes should return an immediate response when the tunnel is up.

This also helps in making the network more secure because the traffic which is supposed to
enter the encrypted tunnel is now not pushed to the default route (ISP) when the tunnel is
down.

Last Modified Date: 06-26-2015 Document ID: FD36695

You might also like