Default Route problems

Jason Fraioli · ‎10-30-2008

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

nate-miller · ‎10-30-2008

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.

pkaretnikov · ‎10-30-2008

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.

Jason Fraioli · ‎10-31-2008

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?

nate-miller · ‎11-03-2008

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.

Jason Fraioli · ‎11-03-2008

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.

nate-miller · ‎11-03-2008

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.

Jason Fraioli · ‎11-03-2008

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?

nate-miller · ‎11-03-2008

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.

Jason Fraioli · ‎11-03-2008

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

nate-miller · ‎11-03-2008

Right, and you know how to get to 172.16.1.2 from this line:

C 172.16.1.0 is directly connected, FastEthernet6/1

So what you need to be careful of:

If there's any network that starts with 172.16.x.x that you're currently relying on the default route to get to (let's say you've got a VPN tunnel to your partner site, their address is 172.16.200.0, and they're on the other side of the firewall. Or you're using 172.16.254.0 as the DMZ, which is on the firewall.)

If you add:

ip route 172.16.0.0 255.255.0.0 null 0

to your core switch, you're not going to have problems getting to any locally connected 172.16.x.x networks, or any network at all that doesn't start with 172.16.x.x.

You might have problems getting to a network that starts with 172.16.x.x if it doesn't live on your core.

I'm just saying "make sure you think it through, and if suddenly you lose access to a network you forgot about, you can fix it just by adding "ip route 172.16.x.x 255.255.x.x 172.16.1.2" to your core as soon as you start getting complaints." :)