uRPF with default route

[MARK HEUZENROEDER]

We're wanting to apply antispoofing on an interface which has a default route pointing out of it.

Does this mean, for traffic ingress to this port, no matter what the source IP address is, the default route will satisfy the condition that there is a route for the source address out of the interface this pkt is currently ingressing on? Hence uRPF is useless in this scenario?

I don't see how loose uRPF would help.

Thanks for any help.

Regards, MH

[Jon Marshall · Accepted solution]

MH

Put simply yes having a default-route will pretty much negate the use of uRPF as the router will always have a path back to the source. Using loose or strict makes no real difference here. In fact you would use strict unless you had multiple paths in and out.

Ordinarily uRPF will not use the default-route unless you use the keyword "allow-default".

In your case you may be better off using traditional acl's to block RFC1918 addressing etc.

Jon

[aacole]

I was also trying to apply this feature, to a VLAN interface on a 4510 switch. The only option I can apply is uRPF with the allow-default, I can add an ACL but as far as I understand that is only parsed if the packet is to be dropped by uRPF. The ACL gets the final deny or permit decision, which If I'm correct in understanding you post, is meaningless. The default option allows any traffic, so non is ever passed via the ACL anyway. Is that correct?

[Jon Marshall]

Andy

"The default option allows any traffic, so non is ever passed via the ACL anyway. Is that correct?"

Yes, because a packet with any source IP will always pass the check.

That said I wasn't aware that an acl would be checked if uRPF was going to drop the packet as it kind of negates uRPF to my mind.

But regardless, yes with a default-route the uRPF check is fairly useless although the packet still needs to arrive on the interface that the default route is reachable by.

If you need a default route and you need to limit the traffic based on source address on the same interface then uPRF is not a solution that will work.

Jon

[aacole]

Thanks Jon,

It does seem pretty usless in that case. I'm now wondering why the only option I get for using uRPF is the "allow-default". I cannot find any documentation that describes this limitation.

What I want to do is to prevent IP source address spoofing on the connected subnet/VLAN.

The configuration has a VLAN with an SVI, this vlan is trunked out of a couple of physical ports to a number of L2 switches. I only want to permit source addresses in the range defined by the SVI, so uRPF seemed to fit the bill.

I suppose I'll have to use ACL's instead, with all the admin overhead that imposes.

Andy

[Jon Marshall]

Andy

Just to clarify.

uRPF would help you here if the default-route pointed out of another interface and it sounds like it might. The key thing is where the default route points to. So

1) you have an internet router and you apply uRFP on the outside interface. But you also have a default route on the router with a next-hop ip address that is reachable via the outside inteface. Then uRPF is fairly useless to you because any source address arriving on that outside interface will always pass the test. This is what the original post was referring to.

2) But on the same internet router you apply uRPF to the inside interface. Now here it is of use because the default route does not come into play. It doesn't come into play because the next hop for the default route is not reachable via the inside interface.

So it's not clear from your scenario where the default route next-hop is in terms of your vlan. If the next hop is not reachable by the L3 SVI for the vlan you want to prevent IP source address spoofing then uRPF would work fine for you.

Jon

[aacole]

Jon,

That does start to make more sense now.

The situtaion I am looking at is as follows:

A 4500 switch, with L2 connections out to user switch stacks, and the default route to the Internet points to another device elsewhere in the network over another interface, not via the user switch stacks.

Each user vlan has an SVI configured on the switch with a /24 subnet. I applied uRPF to the L3 SVI on the vlan.

I was ok with the use of uRPF, until I can to configure it on the switch. The only option I can use is the allow-default, non of the other options are available.

After re-reading your last post, I'm pretty sure that the uRPF configuration is valid and will do what I want.

I think where I initially started thinking this may not work is after reading up the use of the allow-default keyword. This is the message the switch prints when I enter:

int vlan999

ip verify unicast source reachable-via rx

% ip verify configuration not supported on interface Vl999

- must specify allow-default

The L3 SVI will have access to the next hop specified in the default route, but any spoofed address on that vlan will not have a return route, the vlan is a connected network, and so this should work without any problem, do you agree?

[Jon Marshall]

Andy

"The L3 SVI will have access to the next hop specified in the default route, but any spoofed address on that vlan will not have a return route, the vlan is a connected network, and so this should work without any problem, do you agree?"

I do but i am unsure as to why you are getting that error message about having to specify "allow-default". The "allow-default" should be optional. Unfortunately i don't have a L3 switch handy to test with so i would run a quick test if you have the kit. As you are part of BT global services i would assume you could get your hands on a L3 switch :-).

But from what you describe it sounds like uPRF should work fine for you.

Jon

[aacole]

Jon,

I logged into the switch whilst writing my reply, just to sanity check what I was typing!

So far I have not come across any documents that explains why I only have that keyword available, but as i'm now convinced it is doing what I want I'm not too concerned at this time. Thanks for your help.

Andy