ip verify reverse-path

[bfl1]

Has anyone here experienced any problems after implementing this on their firewall(s)?

[jmia]

Hello John,

I have used the anti-spoofing command 'ip verify reverse-path ' on many customer sites without any problems, one thing you need to makesure to have on your config is the default route statement for ip verify to work correctly. Have a read of the following: (Pix IOS 6.3) -

http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_command_reference_chapter09186a00801727a9.html#wp1053009

Hope this helps and let me know how you get on.

Jay.

[bfl1]

Thank you for your reply... I too have used it on many firewalls without any problems, but am about to make it a policy for a large organization that has firewalls throughout the country and want to research any known problems before I do so.

thanks

[haroldworkman]

Just a question to add to this Post. I am trying to impliment this command while using DHCP as my outside interface. I dont have any default routes as Im getting them from BOOTP. Problem is BootP packets are being discarded upon bootup of firewall. Only option is to delete the command, then add it once my firewall gets an ip address and default route. Is this normal?

[mostiguy]

I experienced the same behaviour with 6.3.2. I have not tried it since.

Matt

[scoclayton]

Hey guys,

We discovered this problem to sometime back and added an exception to the ip verify revers-path to allow DHCP packets in to the PIX before a default route was added into the route table. The bug ID is CSCeb19607 - DHCP client fails with ip verify reverse-path enabled and it has been verified as fixed in 6.3(2), 6.2(3), and 6.1(5) (and later releases of each of the trains above). For the person who just reported the issue, can you verify that you are running a resolved version of code (preferably 6.3(4) if you can)? And Matt, any chance you want to re-test? I just tested 6.3(4) in my lab and it worked.

Thanks,

Scott

[haroldworkman]

Scott. thanks for the update. I dont see that bug ID. Is it a Cisco Confidential Bug?

I was running 6.3(3). I can send you a show version if youd like.

[scoclayton]

Dang...yep, it's an internal only bug as we founf it before FCS of the PIX code. If this is a problem in the field, we need to change this ASAP so people can see it. I would go ahead and open a TAC case on this issue. Make sure you let the TAC engineer know about the bug ID - CSCeb19607 just to save some time. This should be fixed so I would guess there may be something else going on. Sorry for the problems.

Scott

[haroldworkman]

Thanks Ill go ahead and have a case opened. I am pretty certain its a problem with this command only because with the command enabled on debugging I see dhcp packets denied. Moment I turn it off I get an IP address.