cisco asa performs ip grabbing

[vitotol85]

Hello, there's a certain problem that's happening the last weeks and it' a real big problem.

All of a sudden the server x.x.x.39 it loses its connection with the default gw which is x.x.x.91

but its connection with another server that has a public ip on the same subnet x.x.x.32 is up.

so during the problem the 39 can ping 32

32 can ping the gw 31

but 39 can NOT ping 31 so the rest of the world too.

To solve this problem i ssh on the private ip of 39 server and i give service network restart

and the server goes back online. this can happen a few random times during the day.

i sent a ticket to the datacenter support and they told me that they saw another mac address using

the public ip x.x.x.39 and they report it as ip grabbing. the mac address that grabs the ip is a Cisco ASA

that belogs to us and we use it for site-to-site vpns with the .39 server.

the cisco and 39 server has one more interface on the subnet 192.168.2.0/24

there are about 10 vpns that from them the 3 are using the .39 public ip for the interesting traffic

so except the "exempt nat rule" on the inside interface i have one more that translates the incoming packets and changes the source addr from 192.168.2.10 to x.x.x.39 so the packet when it's received on the other end to be seen as interested traffic.

what might be the problem of this situation? do you have any clue? maybe the VPNs using the public ip conflict the network???

[vitotol85]

hello,

The problem just happened again. this time  before i restart the network service i gave "ip neighbor stale" and for  the gateway x.x.x.1
the entry was like this:x.x.x.1 dev eth1 lladdr 46:7c:00 STALEafter the service restart it changed to REACHABLE

[vitotol85]

as i told you on a previous post i had to use the public ip x.x.x.39 for the interested traffic of 3 VPNs so I added 3 static NAT policy rules. the policy rules look like this:

ORIGINAL

source: 192.168.2.100 (x.x.x.39 server private interface)

destination: y.y.y.y

TRANSLATED

interface: outside

use ip address: x.x.x.39

i have added those 3 policies because i have to use a public ip for the interested traffic for 3 VPNs

and without these policies i was getting to the other side with the ip 192.168.2.100 and the packets was dropped.

Is this problem because of these 3 rules and why?

please help me.

[Patrick Colbeck · Accepted solution]

Hi

Its not clear what your toplogy and NAT config look slike exactly. Howvere in general if you configure NAT on an ASA5500 the the ASA5500 will respond to ARP request for the address that you have NATed something to. Thats how it ssupposed to work. If you have a physical box with IP address X on an ASA5500 interface and also have address X as an address that you are NATing to on the same interface then indeed other devices on the same subnet are going to get really confused as to which one they should be talking to. You are in effect poisoning the arp cache of all teh other devices on the same L2 network that are trying to talk to that server.

[vitotol85]

hello, it's supposed not to be on the same network but I do not have a clear view because the machines are on a datacenter.

What I did to give an end to this big trouble was to ask the datacenter's support to add a manual entry on their arp table. I know that this is not a proper solution but more of a workaround.

You said that the ASA by default it responds to arp requests for IP address that performs NAT. Is there anyway to configure it not to do that???

Thanks Patrick for your respond.

[Patrick Colbeck]

Not really I am afraid as thats how it ssupposed to work. Consider the attached diagram.

The server with a real IP of 172.11.1.23 is being NATed to 10.1.1.19 how does the client PC on the "outside" talk to it ?

It arps for 10.1.1.19 and the ASA5500 replies to this ARP with the mac address of its "outside" interface. The same thing happens if we replace teh PC with a outer the router will ARP for 10.1.1.19 and needs to get back teh mac address of teh ASA5500 "outside" interface so that it can send packets to the ASA5500 where they are NATed to 172.11.1.23 and passed to the server. If we were to stop the ASA5500 replying to these ARPs then there would be no way for teh PC to reach teh server and teh whole thing would be pointless.

What I suspect is going on with your setup is that youi have a real server on the "outside" network that also has address 10.1.1.19 so devices on the outside network will get either the MAC address of the server or the ASA5500 interface. This means that you have an incorrectly configured network.  The NAT in question doesnt have to apply to a real server on the "inside" it can be on any interface or even be a VPN NAT the salient point is that if the logical "outside" interface for the NAT is the same interface as a server with the same address (in this case 10.1.1.19) things are going to break.