ip verify unicast and DHCP

[glenthms]

IOS

c1700-advsecurityk9-mz.123-14.T5.bin

Why do I have to remove the command

ip verify unicast source reachable-via rx allow-default allow-self-ping

from the interface to get DHCP to work to my ISP?

Interface config

interface Ethernet0/0

description Outside LAN

bandwidth 384000

ip address dhcp

ip access-group allowed

ip verify unicast source reachable-via rx allow-default allow-self-ping

no ip redirects

ip inspect myfirewall out

ip nat outside

ip virtual-reassembly

full-duplex

crypto map r2d2

ip inspect audit-trail

ip inspect udp idle-time 1800

ip inspect dns-timeout 7

ip inspect name firewall tcp timeout 3600

ip inspect name firewall udp timeout 15

ip inspect name firewall http java-list 1 timeout 3600

ip inspect name firewall icmp alert off

ip inspect name firewall ftp timeout 3600

ip inspect name firewall smtp timeout 3600

ip inspect name firewall sqlnet timeout 3600

ip inspect name firewall tftp timeout 30

ip inspect name firewall cuseeme timeout 3600

ip inspect name firewall h323 timeout 3600

ip inspect name firewall realaudio timeout 3600

ip inspect name firewall streamworks timeout 3600

ip inspect name firewall vdolive timeout 3600

ip inspect name firewall fragment maximum 256 timeout 1

ip inspect name firewall netshow timeout 3600

ip inspect name firewall rtsp timeout 3600

ip inspect name firewall sip timeout 3600

ip inspect name firewall skinny

The only way I can get DHCP to work is to remove the DDOS commands on the E0/0 interface.

I read up on this command a little and it states

http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/hsec_r/sec_i2h.htm#wp1147566

Note If the source address of an incoming packet is resolved to a null adjacency, the packet will be dropped. The null interface is treated as an invalid interface by the new form of the Unicast RPF command. The older form of the command syntax did not exhibit this behavior.

I dont want to loose the features this commands offers for DOS attacks but with it enabled DHCP breaks.

anyone have any suggestions?

[pkhatri]

You do have a default route pointing to your ISP, don't you ?

Paresh

[glenthms]

There is no default route set as I get that from the DHCP server.

[pkhatri]

It seems that this may be the reason that the RPF check is failing. It might be worth tryin something like the following:

ip route 0.0.0.0 0.0.0.0 Ethernet0/0 192.168.1.1 200

The 192.168.1.1 is just a dummy address (pick any address that you don't use in your network).

The above should result in the RPF check passing and then the default route learned via DHCP will be installed in preference to the above static (which I've used an admin distance of 200 for).

Never tried such a thing myself but it's worth a shot.

Hope that helps - pls rate the post if it does.

Paresh

[pkhatri]

Actually, I don't think you need the dummy next-hop, just try the following:

ip route 0.0.0.0 0.0.0.0 Ethernet0/0 200

Paresh

[tekha]

Wouldn't the router always use this default route, and not the one it gets by DHCP?

I mean the default route learned by the DHCP server has an administrative distance of 254, so this one is better, wright?

And since this is pointing to an Ethernet interface, you would end up with a huge arp table, before the router runs out of memory.

[pkhatri]

OK, I hadn't realised that the default installed through DHCP had an AD of 254. If that is the case, you are correct and what I suggested will not work at all.

Thanks,

Paresh

[tekha · Accepted solution]

Perhaps one could spice up the "ip verify unicast" with an access-list.

Maybe like so:

interface Ethernet0/0

ip verify unicast source reachable-via rx allow-default allow-self-ping 101

!

access-list 101 permit udp any eq bootps any eq bootpc

[glenthms]

Great Idea. Let me try that this evening and Ill let you know how it goes.

[tin]

I know this is a very old thread. But I just came across it today. IMO, adding the suggested ACL will basically defeat the source verification because any traffic on UDP 67/68 (forgot which one) is unrestricted.

Strangely, it seems the ip verify config only affect some specific DHCP clients. Most devices are not affected. I am still trying to figure out why.