Just had an interesting problem with a customer that seems a bit obscure, so I figured I would write it down to help someone else. All of the other solutions to this issue focus solely on there being a problem on the Windows side, which may not necessarily be the case.
Situation: customer is setting up a Windows 2008 R2 server in a VMware cluster, on a VLAN that is sitting behind a firewall. The firewall is is the gateway for the VLAN (say 192.168.34.1). When configuring the network interface on the server, picking ANY IP address in the 192.168.34.0/24 network results in the error message “Windows had detected an IP address conflict”. This happens even if there are no other devices on the VLAN aside from the firewall.
The issue? There was a static (identity) NAT entry in the Cisco ASA firewall for 192.168.34.0/24. By default, Cisco firewalls will proxy ARP for NAT entries.
- (8.3(1), 8.3(2), and 8.4(1)) The default behavior for identity NAT has proxy ARP disabled. You cannot configure this setting.
- (8.4(2) and later) The default behavior for identity NAT has proxy ARP enabled, matching other static NAT rules. You can disable proxy ARP if desired.
This is desirable behavior for a firewall on the edge of the network because the upstream router needs to know where to send traffic for NAT’ed hosts. For internal firewalls this can cause issues, especially with 8.4 code where you need to setup identity NAT to exempt devices from NAT.
The solution? Add “no-proxy-arp” to the end of your identity NAT statements:
nat (inside,outside) source static obj_Internal obj_Internal no-proxy-arp route-lookup
The other (less desirable) solution is to disable the ARP-checking functionality in Windows, but this means it won’t be able to detect a legitimate IP conflict. You can do this through a quick registry hack: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, create a DWORD named “ArpRetryCount” with a value of “0?.