Strange Issue of IP Getting Claimed by FTD's MAC Address

[Matthew Martin]

Hello All,

In one of our sites over the weekend, the Domain Controller there rebooted. When this happened, it looks like some other device went and claimed the DC's 2 IP address. When I ran a show arp and show mac on the switch, I could see that the MAC Address pointed back to our FTD device's inside interface in that location...

After fiddling around, trying to figure out what/why this address was getting claimed, we finally just shutdown the Port-channel for the FTD, cleared arp for that IP, and then reset the nic on the DC, and then a few seconds later the DC reclaimed it's IP Addresses. After we confirmed the DC was back up, we re-enabled the port-channel, and all seems ok again.

But, we're worried this could happen again if/when the DC reboots again. So we're hoping we can try and figure this out...

The DC has 2 vNIC's. And actually BOTH IPs were getting claimed by the FTD's MAC Address.
For example, the DC has the IP's:
10.70.1.3
10.70.1.4

Both of those above, plus 10.70.1.2(*and the FTD's actual inside interface address) were all being claimed by the FTD's MAC Address, according to the switch. So it just seems like something was taking the addresses on the lower end of 10.70.1.0/24. Since nothing is using 10.70.1.2 that one is still being claimed by the FTD... As I'm wirting this I discovered that .2 and .5 are the old DC. So not sure if this is a coincidence, but all those addresses are related to Domain Controllers.

Our FTD in this location has basically gotten replaced by another device for Firewall. But, it's still up as we have a VPN tunnel configured for an on-going project that we can't shutdown right now...

Super confused with this... Could anyone point me in the right direction?

Thanks in Advance,
Matt

[Rob Ingram · Accepted solution]

@Matthew Martin do you NAT proxy arp configured?

If you use addresses on the same network as the destination (mapped) interface, the threat defense (FTD) device uses proxy ARP to answer any ARP requests for the mapped addresses, thus intercepting traffic destined for a mapped address.

https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/740/management-center-device-config-74/interfaces-settings-nat.html

[Matthew Martin]

Hey Rob, thanks for the reply.

So I didn't setup this Tunnel, that's on the FTD. But I just started poking around and found this in Devices > NAT... There's a couple of rules at the top that look to be named as though they're for this project using the Tunnel... All the other rules below these top 3 shows "no-proxy-arp" under the options column, but the top 3 rules do not.... 

There's a Rule using dns servers' object, see below...

That can't be a coincidence...?

-Matt

[Rob Ingram]

@Matthew Martin is that NAT rule actually required? run - "show nat detail" "show xlate"

If it's not required, disable it and see if the issue is resolved if you reboot the DC again.

[Matthew Martin]

This is from "show nat detail":

2 (any) to (any) source static internal_dns_servers internal_dns_servers  destination static OCI OCI
    translate_hits = 0, untranslate_hits = 0

And then "show xlate":

NAT from any:192.168.1.25, 10.70.1.2, 10.70.1.3,
    192.168.1.10, 10.70.1.4 to any:192.168.1.25,
    10.70.1.2, 10.70.1.3, 192.168.1.10,
    10.70.1.4
    flags sIT idle 264:24:35 timeout 0:00:00

Those are all DC addresses configured in the "internal_dns_servers" object.

I'm guessing this isn't needed since there have been no hits...

-Matt

[Rob Ingram]

@Matthew Martin disable it. Also try not to use "any" for the interfaces in NAT rules.

[Matthew Martin]

Hey Rob, thank you!

Ok, thanks for the info on the "any" portion, was unaware of that.

We'll disable that today. We won't know for certain until that reboots again. But it definitely feels like that's the problem.

Thanks Again, much appreciated!

-Matt