Problem with ARP and PIX

[romchik]

I have a problem with a new connection that I made for a new network segment which is directly connected to a PIX. The PIX is a 520 running ver 5.2.

The workstations and servers are connect to a Catalyst 2950 which is connect to the PIX for the gateway (no other router in between). I was having issues accessing some devices on that same network segment and later it was found that the PIX was responding to ARP requests instead of the machine that was being accessed. So basically, if computer A is trying to talk to computer B which are on the same network, it is actually going to the PIX (like computer B is on a different net). If I disconnect the PIX everything is fine but if I reconnect it, the problem starts all over again. This is also random and happens to several different computer/server at different times. Any ideas?

Thanks,

Roman

[mostiguy]

The pix will proxy arp, which makes sense for when statics and globals are in use (i.e, it proxy arps on behalf of those behind it as they are on a different segment ethernet wise and could not response to arp themselves). Why it would proxy arp on the inside is a bit curious. You could try:

sysopt noproxyarp inside

That said, you might want to look at your configuration, as I believe the pix should only response to arp requests for its interfaces, and IPs used for static or global addresses. If you have a support contract, you also might want to upgrade the PIX OS, as that is a very old version, and I have no idea if there were any proxyarp bugs in it

[romchik]

thanks for the reply... I understand the proxy function of the PIX but would it make any difference if this was a DMZ interface ie (eth2)? These hosts that are having problems or on the same net and are not trying to access any other net. Problem happens when the PIX is connected.

Thank you for your suggestions, I will try them!

[csturmey]

I had a similar problem. It occured because two interfaces shared the same physical cabling. Pinging the address for the first time replied with one response and then nothing. A packet capture revealed that the second interface (believing that the mac address was on its network) replied momentarily later than the first interface.

The solution was to segregate the second network onto its own physical cabling.

If this does not work, the other option that you have is to manually enter the correct addresses into the arp table on the PIX.

HTH

Colin

[m.berry]

Does the PIX have the correct subnet mask for the DMZ interface? If the mask is too long, it may think the target host is not on that directly connected interface and therefore make a proxy ARP response.

[romchik]

Thank you Gentlmen for your replies... The PIX has different physical cables connecting the inside and the DMZ interfaces. I also confirmed the mask and that is set up correctly. I'm tring to get the latest PIX OS to see if I can do a 'no arp' command since the 5.2 OS does not support that function.

Thanks,

Roman

P.s If anyone has any other suggestions PLEASE feel free to post.

[tin.ngo]

Hi Roman,

I am experiencing the same problem on a Pix running 6.2.3. Servers on same subnet can not talk to each other because the Pix sends the Arp reply first.

My current work around is adding static arp on each server. Have you found a solution for your problem?

[tin.ngo]

I should explain how the problem started:

The pix has 4 interfaces as follow:

Inside : 10.202.254.0/26

Outside: 10.203.1.64/26

DMZ1: 10.203.1.128/26

DMZ2: 10.203.1.192/30

This set up has been working fine for a few years. Recently things change and there were users coming from DMZ2 with a 10.x.x.x network. We had no choice but route the whole class A 10.x.x.x network back to DMZ2. The 3 lines added to the Firewall were as follow:

route dmz2 10.0.0.0 255.0.0.0 10.203.1.193

static (dmz2,outside) 10.0.0.0 10.0.0.0 netmask 255.0.0.0

static (dmz2,dmz1) 10.0.0.0 10.0.0.0 netmask 255.0.0.0

Since then the problem started where servers on the same subnet such as on DMZ1: server_1 with IP 10.203.1.130 can not ping server_2 wit IP 10.203.1.131. Packet trace showed that when server_1 arp request for server_2, the Firewall arp Reply with its Mac address. Debug arp on the firewall also showed the following results with 10.203.1.129 being the IP of DMZ1 interface. The Firewall is arping for itself ??

90: arp-send: arp request built from 10.203.1.129 00e0.b606.81df for 10.203.1.129

91: arp-send: arp request built from 10.203.1.129 00e0.b606.81df for 10.203.1.129

92: arp-send: arp request built from 10.203.1.129 00e0.b606.81df for 10.203.1.129

93: arp-send: arp request built from 10.203.1.129 00e0.b606.81df for 10.203.1.129

94: arp-send: arp request built from 10.203.1.129 00e0.b606.81df for 10.203.1.129

95: arp-send: arp request built from 10.203.1.129 00e0.b606.81df for 10.203.1.129

96: arp-send: arp request built from 10.203.1.129 00e0.b606.81df for 10.203.1.129