Block bogus RFC1918 traffic from reaching Internet

[MisterAG]

I have several RFC1918 subnets on various interfaces of my Fortigate. My Fortigate is advertising info OSPF a default route. This is causing my internal routers to pass up traffic to unused subnets (like 192.168.200.0/24) to the Fortigate. The Fortigate in turn has a default route out the the Internet by way of my provider, and is passing the same traffic upstream there. What is the most efficient (configuration / performance / administrative) way to stop that traffic from crossing the Fortigate? I' m thinking of a blackhole route for 192.168.0.0/16 with a high administrative distance vs a Firewall policy on any > external Ideas?

[rwpatterson]

Why would you have traffic to RFC1918 subnets that aren' t in your organization? That' s just plain weird (to me)... Anyhow... You could create a single policy inside->WAN and deny all RFC 1918 traffic there. That would effectively keep that stuff off the WAN.

[MisterAG]

We don' t have any outside... But we' ve just got a static 0.0.0.0 pointing to the Internet. That default route will send out all unknown destinations (including RFC1918) to the next hop, regardless of if it is private or not.

[emnoc]

What , that doesn' t make any sense ? Are you advertising rfc1918 or concern with rfc1918 address host going out to the internet ( leakage ). If your advertising osfp routes to you upstream or usptream router or whatever your trying todo, then filter the ospf routes from your advertisements. if your trying to prevent sources that are RFC1918, APIPA, martians, than don' t allow them by the fwpolicies. if your worried about spoof' d address, the unit will protect you from any sources not in the unicast route table.

[MisterAG]

Internal Routers speak OSPF with Fortigate. Fortigate has a default route configured to the Internet. All internal routes are advertised into OSPF. At this point, if you look at a routing table you' ll see entries for all of your internal networks and nothing from the Internet. I don' t speak BGP with anyone upstream - I just have a single static default route configured on my Fortigate out the external interface. At this point, my internal routers still don' t know how to reach the Internet because they still don' t have any default route configured. To solve this, you use #default information originate On your egress OSPF router from your network (Fortigate). Now all the internal routers know to pass any traffic for unknown networks to the Fortigate, which has been configured to pass any unknown traffic up to the default gateway that was statically configured. Unknown networks are anything that isn' t in the main OSPF network table or a static route. This includes routes to say Google and Amazon, but it also includes unknown routes in the RFC1918 address family. Try it - do a traceroute on your own Fortigate for an RFC1918 network that you don' t use on your own LAN. I bet it' ll end up trying to egress your own Fortigate. If you' ve got a rule for your Internal > External that allows say ICMP to any destination, you' ll even be able to send a traceroute out to an unused RFC1918 address (try 10.99.88.77). If you' re passing that traffic out of your network to the Internet, you' re generating the bogon traffic that I' m trying to block. My question is, is the easiest way to do so by firewall policy?

[ede_pfau]

I' ll be lazy and just cite my own post here:

You can prevent forwarding such traffic by creating blackhole routes with a very low priority. They will not be followed if there' s a valid route to the tunnel; and a blackhole route will discard any traffic sent to it. There are posts about blackhole routes on the forum, like this one here: https://forum.fortinet.com/FindPost/87069 I' ve posted the CLI commands for the most common RFC1918 private networks there. Be aware of Bob' s comment on blackhole routes interfering with Policy Based Routes - which might or might not affect your setup.

As I said, this just has the most common RFC1918 networks covered. YMMV.

[MisterAG]

Thanks ede_pfau. This is what I wanted, and what I figured that I needed to do. I was just looking to see how anyone else was doing it. I ended up blocking the routes by way of firewall policy to ensure that it would show up in the GUI. I figure that blocking it by policy passes the ' troubleshooting at 03:00 AM' test better than a CLI only command, but I' ll evaluate this as well. It really is an in your face GUI option vs a CLI only option - one is very obvious from the GUI, one is very obvious from a config change archive.

[ede_pfau]

I always thought of default blackhole routes as a means of last resort - no matter what I (mis-)configure in the policy table this sort of traffic will not make it to the WAN. As the distance parameter is set utmost high there' s no chance legitimate traffic will be blackholed. And regarding the ' obviousness' in the GUI, the Routing Monitor tells it all. BH routes will show up as active, with destination ' Null' . Easy to spot.

[MisterAG]

Even better then.

[FortiRack_Eric]

this is the way to go... blackhole all not specified RFC 1918 traffic. config router static edit 0 set blackhole enable set distance 254 set dst 192.168.0.0 255.255.0.0 next edit 0 set blackhole enable set distance 254 set dst 172.16.0.0 255.240.0.0 next edit 0 set blackhole enable set distance 254 set dst 10.0.0.0 255.0.0.0 next end This is a (part) of a standard script we provision on every FGT unit. Cheers, Eric