We recently ran into a very interesting issue with a client that was utilizing OSPF in their network. The issue was that we had everything working great in OSPF, however there were some incoming VPN connections to the FortiGate unit that were getting IP’s from the FortiGate. The subnet that was being handed out, for this example we will say 192.168.50.0/24, did not exist anywhere on the rest of the network (specific to the IPSEC-connected VPN clients only), and of course the rest of the network had no idea what this subnet was, or how to route to it (even though we had configured the FortiGates OSPF to redistribute static entries – and the IPSEC VPN was set to create routes for each connected device).
Basically here is the setup:
- IPSEC VPN (dialup) was set to distribute IP’s for an internal subnet that was nowhere else on the network – it was set in mode-cfg
- Network using OSPF (all other routes were working – including ssl.root)
- IPSEC VPN clients could connect and hit the internal network, but the internal network couldn’t communicate back (no route to host)
- We found if we created static routes on the other internal routers to point to the FortiGate it would work
- Creating a static route on the FortiGate pointing to the IPSEC interface did not work (the route never displayed in the routing monitor)
- IPSEC VPN clients did have a static route on the FortiGate once connected, but that was not being redistributed
- Firewall policies/rules were in place to allow traffic flow to/from internal network
- We wanted this all to work via OSPF
After trying a multitude of different things, from tweaking the VPN to adjusting routes, we were unable to get the FortiGate to tell the OSPF neighbors that it had the 192.168.50.0/24 subnet attached, even though it could ping that subnet, and static routes on the other routers to the FortiGate did work. But this wasn’t what we wanted, the goal was to make this all happen via OSPF so we didn’t have to have a bunch of static stuff in there.
This is where we learned about something not highly documented, and very interesting, called a Blackhole Route. A blackhole route is exactly what you would think; it is a route that drops all traffic that is sent to it, FortiGate documentation mentions it is similar to a /dev/null interface in Linux.
So how does a route that drops everything sent to it help us since we actually want the traffic to go through? Well it turns out this is pretty simple, by changing the interface of our static route to “set blackhole enable” instead of the IPSEC VPN interface, it will actually publish this route across OSPF. Since the route is then set to drop all traffic sent to it we just need to ensure that the FortiGate has more specific routes in place for the IPSEC VPN clients, which is taken care of by default for the IPSEC phase1-interface.
For your viewing pleasure here are the basics of what we needed in order for this to work the way we wanted it to. For the sake of our client, any specific information has been removed/changed.
config router static
set blackhole enable
set dst 192.168.50.0 255.255.255.0
config vpn ipsec phase1-interface
set type dynamic
set interface “interface name here”
set dhgrp 2
set xauthtype pap
set mode aggressive
set mode-cfg enable
set proposal 3des-sha1
set authusrgrp “local_user_group”
set ipv4-start-ip 192.168.50.1
set ipv4-end-ip 192.168.50.5
set ipv4-netmask 255.255.255.0
set psksecret ENC xxxxxxx
The cool thing here is that the blackhole interface could be used for a lot more than what we needed it for. Another example might be if you wanted to just drop packets bound for a specific subnet without providing a response, meaning that whoever sent the packet will get nothing back and will get no insight into that particular subnet. Another method might be that you want to take any requests to youtube.com and instead of taking up resources on your FortiGate (using Web Filtering), you could just create a blackhole route for all youtube.com’s IP range. It would be as simple as:
config router static
edit 99 <- don’t use 99, use the next unused integer so probably something like edit 5, etc. depending on how many routes you have setup.
set blackhole enable
set dst 18.104.22.168/16
Pretty easy stuff once you actually look at it, but not something I had actually come across before as needed in this type of environment, however now that I know about it I can see a lot more uses for it! Thank you for reading and be sure to let us know if you have any questions!