Periodically we perform network discovery scans to see what is on our network. When we scan a subnet that is not in use (no vlan or vlan interface exist) we get results back saying that there was a device found and that it is our firewall.
Obviously this is because our scaning workstation hit our core which could not find a matching route for the subnet in question, and forwarded our scan out the default route to our firewall.
How can I prevent this from occuring? If we don't have a vlan or vlan interface created for a particular subnet, how can we drop all requests to that subnet without the request going up to the firewall (via the default route)?
Thanks in advance
I don't know how you're hierarchialy set up- if all your routes are neatly summarizeable, you could null route your traffic at the core.
Let's say you've got networks scattered from 10.0.0.0 through 10.63.0.0, and they're ALL suppose to be behind the core.
ip route 10.0.0.0 255.192.0.0 null0
That would take care of it.
What you need to be careful of- if you're currently relying on your default route to get your through the core for a network, because you don't have an explicit route to it (let's say that 10.2.0.0 / 24 is your DMZ, on the other side of your firewall) then you're going to break this.
you'd need to have a more exact route to this other network existing in your network somewhere- either via a dynamic routing protocol, or statics.
Understand that that null-route supernet that we've just added won't junk valid traffic- your core will see a more specific route, and prefer to use it. So traffic to 10.1.0.0 and 10.4.0.0 will get routed to the right place. But traffic to that unused 10.30.0.0 network? It'll just fall on the floor.
Just make sure that you've got a good grasp on your network topology before you configure a null-routed supernet. If you've been using the default route to get you through the core for some networks you'd forgotten about... you could be in an outage situation until you correct it.
The above is a nice clean method but on occasion due to circumstances I've actually gone and created the missing networks either as a real interface on the core, as a loopback, or as a route to null. It will accomplish the same task but you don't risk breaking routing. On the other hand it's somewhat sloppy and later on you can run into issues once you actually put those networks into place somewhere else.
currently all our networks aggregate at the core, then there is a default route to our firewall. We are not using a routing protocol since we only have one core switch.
I assume in this regard, I'll just have to null route each network individually then right?
It depends upon how many non-contiguous networks you have.
If you've got a single summary network that you're breaking into chunks, then you can get by with a single null route statement taht covers everything. If you've got A bunch of disparate networks that you can't summarize, then yes, you'll need individual networks.
As I mentioned before- your null-route summary can include your 'live' networks- no ill effects will happen, as long as they're all being routed off of the core.
Nate, I appreciate this valuable information!
Will the default route take precedence over this supernet route? Currently I am running a class B 172.16.0.0 network broken down into class C subnets. 172.16.1.2 is my firewall, so I am using a default route to point traffic at that address.
"ip route 0.0.0.0 0.0.0.0 172.16.1.2"
Will this supernet route break that?
"ip route 10.0.0.0 255.192.0.0 null0" -- Obviously I would have to modify this for my address space, I am just posting the example you gave.
If you put:
ip route 172.16.0.0 255.255.0.0 null 0
in your core, you'd probably be good. This would mean any address that started with 172.16 would be thrown to the bit bucket, if a more specific route didn't exist.
Your default route would cover non 172.16.x.x routes, and feed them to your firewall.
You'd need to be careful about any 172.16.x.x routes that you expect to be on the other side of that firewall, though- be it because they're a VPN tunnel or on the DMZ, or something else. Those you'd need to build routes to and point them at your firewall, to be more-specific and override this null-route.
I guess this is the part I really don't quite understand.
"Your default route would cover non 172.16.x.x routes, and feed them to your firewall."
I guess that's the problem though, I don't have non 172.16.x.x networks. I only have about 40 class C subnets from the 172.16.x.x Class B network. If I supernet the entire 172.16.x.x network, how do I route traffic to my firewall?
The route to your firewall should show up as a "C" route- directly connected.
The switch will know how to get to every "C" route, because it's going to be more specific than the 172.16.0.0/16 null route you're creating.
You just need to make sure that no other 172.16. network that you intend to get access to doesn't reside directly off your core.
here is a snippet from my route table. 172.16.1.0 is the network between my core and firewall. 172.16.1.2 is the firewall. The route to my firewall shows as a S* (static default) route.
C 172.16.1.0 is directly connected, FastEthernet6/1
C 172.16.51.0 is directly connected, Vlan51
C 172.16.76.0 is directly connected, Vlan76
C 172.16.44.0 is directly connected, Vlan44
C 172.16.12.0 is directly connected, Vlan12
S* 0.0.0.0/0 [1/0] via 172.16.1.2