5506 with dhcpd compatibility issue?

[Patrick Beaven]

Hello, 

Has anyone seen this and have a work around for it? I just deployed several ASA-5506 firewalls with just a basic setup for internet access and vpn to office. They work fine with my Linux laptop i get an address and can surf etc. When i plug in any windows XP machines they work fine too. But if i try to connect with Windows 7 or Windows 10. I don't get an address! I can statically assign one and it all works fine. Just cant get a dhcp assigned address. I'm running 9.6.1 firmware and have tested this with several pc's and it always works the same way! Anyone with a work around or known bug on this? Thanks for any response!

Pat 

[Pulkit Saxena]

Pat,

Tried looking for this but could not find a known issue or caveat. Few things that we can try,

a) Take packet captures for working and now working scenario and see what is different in windows 7 DHCP request which ASA is not acknowledging.

b) Try gathering the output of 'debug dhcpd packet' and 'debug dhcp event' during a time when your client is looking for an IP address. That might give some clue as to what's going on.

c) Open up a TAC case for further investigation.

d) Perform a pro active upgrade to an interim image of 9.6.1 which is Cisco recommended :

https://software.cisco.com/download/release.html?mdfid=286283326&softwareid=280775065&release=9.4.1%20Interim

Let me know if you collect the outputs.

-

Pulkit

[Patrick Beaven]

Thank you for the reply! I did just find the issue!. Looks like a proxy-arp problem. Here's what I found.

If I connected via Linux, windows 8 it worked fine! If I connected via windows XP, 7 OR 10 it would fail to get an ip address. I found some reference to a proxy-arp issue so disabled proxy arp ie.

sysopt no proxyarp inside.

This fixed the issue! now all OS'es are supported and function :)

Thanks again for the advice!

[Pulkit Saxena]

Pat,

Thank you so much for the update and I am glad that it is working by disabling proxy arp on inside. However this has made me even more curios. 

After doing further research and some testing, I think we might be having one of the below nat statements :

a) nat (inside,inside) or b) nat (inside,any) or c) nat (any,any)  or identity nat and proxy arp is enabled on the nat statement.

If we do have such nat statement, even adding a "no-proxy-arp" at the end would be an appropriate solution.

Check this link :

http://www.cisco.com/c/en/us/support/docs/security/adaptive-security-appliance-asa-software/116154-qanda-ASA-00.html

After going through some windows documentation, it seems that for some Windows variant before assigning the IP address on the NIC, it does a grat arp and since ASA was configured to perform proxy arp, it started replying for the same and thus the windows machine never got an IP address.

Again captures would have given a clear picture on this. Anyways, if disabling proxy arp on inside interface is not affecting your any other service, we should be good.

Thanks for the update. :)

Cheers,

Pulkit