|
When FortiGate performs route lookups restricted to a particular interface, blackhole routes will also be checked. This can potentially cause traffic drops if the blackhole route is more preferred than the intended route.
Blackhole routes are static routes with ‘set blackhole enable’ configured. The 'match all interfaces' behavior is by design and should be considered when configuring blackhole routes.
Common scenarios in which FortiGate may unintentionally match a blackhole route and drop traffic include the following:
- remote gateway of IPsec tunnel.
- Reverse Path Forwarding check. If there is a better blackhole route, FortiOS ignores less specific routes as if ‘strict-src-check’ is enabled.
- Link monitor.
- local-out traffic such as system DNS or system FortiGuard traffic.
Ping traffic example:
FGT61F-A # get router info routing-table all
--output omitted--
Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via 10.0.0.1, wan1, [1/0]
C 192.168.102.0/24 is directly connected, internal1
C 10.0.0.0/30 is directly connected, wan1
S 172.243.0.0/16 [10/0] via 10.0.0.1, wan1, [1/0]
S 173.243.138.91/32 [10/0] is a summary, Null, [1/0]
Because both a default route and a 172.243.0.0/16 route are present in the routing table, an administrator may mistakenly expect that 173.243.138.91 is reachable over wan1. However, any attempt to access 173.243.138.91 over wan1 will fail with 'Network is unreachable' because the more specific blackhole route was matched.
FGT61F-A # execute ping-options interface wan1
FGT61F-A # execute ping 173.243.138.91
PING 173.243.138.91 (173.243.138.91): 56 data bytes
sendto failed: 101(Network is unreachable)
sendto failed: 101(Network is unreachable)
sendto failed: 101(Network is unreachable)
sendto failed: 101(Network is unreachable)
sendto failed: 101(Network is unreachable)
Matching intended routes:
When configuring blackhole routes, it is recommended to use less specific prefixes than existing intended routes, to ensure intended routes are matched first.
Where this is not possible, the traffic can be allowed by configuring an intended route with the same prefix, administrative distance, and same or earlier priority, see the article 'Routing behavior depending on distance and priority for static routes' and the example below.
The example blackhole route has the following attributes:
- prefix 173.243.138.91/32.
- administrative distance 10.
- priority 1.
FGT61F-A # get router info routing-table all
--output omitted--
S 173.243.138.91/32 [10/0] is a summary, Null, [1/0]
A similar static route can be configured over wan1 to allow the traffic.
config router static
edit <index>
set status enable
set dst 173.243.138.91 255.255.255.255
set gateway 10.0.0.1
set distance 10
set priority 1
set device "wan1"
next
end
FGT61F-A # get router info routing-table details 173.243.138.91
Routing table for VRF=0
Routing entry for 173.243.138.91/32
Known via "static", distance 10, metric 0, best
* directly connected, Null
* vrf 0 10.128.202.1, via wan1
Since there is a wan1 173.243.138.91/32 route with the same administrative distance and priority and there is no issue with the ISP, 173.243.138.91 is now accessible over wan1.
FGT61F-A # execute ping 173.243.138.91
PING 173.243.138.91 (173.243.138.91): 56 data bytes
64 bytes from 173.243.138.91: icmp_seq=0 ttl=54 time=1.4 ms
64 bytes from 173.243.138.91: icmp_seq=1 ttl=54 time=1.3 ms
64 bytes from 173.243.138.91: icmp_seq=2 ttl=54 time=1.2 ms
64 bytes from 173.243.138.91: icmp_seq=3 ttl=54 time=1.2 ms
64 bytes from 173.243.138.91: icmp_seq=4 ttl=54 time=1.3 ms
--- 173.243.138.91 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 1.2/1.2/1.4 ms
By configuring less specific blackhole routes or configuring routes to allow specific traffic, an administrator can prevent unintended drops from matching the blackhole route.
|
