cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
826
Views
11
Helpful
10
Replies

ARP issue and PIX firewall

bevans
Level 1
Level 1

I have a PIX 515 that is doing static NAT translations (using static and alias entries). I have one remote access server running Citrix. We have had some issues connecting to that server internally. I have found that when I ping it, 9 out of ten tries is times out after the first attempt. When I do an "arp /a" from my workstation it comes back with the MAC address of the internal interface of my PIX. If I try doing the ping and clear my arp cache manually, after ten or more tries is will successfully ping the right device - and then go right back to the PIX MAC address. This setup is a pretty typical configuration for us. What could be wrong?

1 Accepted Solution

Accepted Solutions

gfullage
Cisco Employee
Cisco Employee

Sounds like the PIX is answering the ARP requests for the Citrix servers' MAC address. Turn off proxy ARP on the PIX on the inside interface with:

> sysopt noproxyarp inside

View solution in original post

10 Replies 10

gfullage
Cisco Employee
Cisco Employee

Sounds like the PIX is answering the ARP requests for the Citrix servers' MAC address. Turn off proxy ARP on the PIX on the inside interface with:

> sysopt noproxyarp inside

Thank you both for your post. I reviewed the command "ip proxy-arp." Since it is a per interface command, I would issue "no ip proxy-arp" on the internal interface of my PIX? I just wanted to verify that this is correct. Also, might this have any negative side affects? Thanks!

It seems that you have the routers "ip proxy-arp" command confused with the Pix. As posted above, the pix would use the command "sysopt noproxyarp inside". You could turn off proxy-arp, but this shouldn't be happening actually.

What version are you running?

And you have no alias commands.....

Can you post the static command you're using for the Citrix server?

Shannong,

Our PIX is running 6.1(2). An example static entry:

static (inside,outside) 100.20.50.9 10.10.1.22 netmask 255.255.255.255 0 0

For that I also have an alias entry:

alias (inside) 10.10.1.22 100.20.50.9 255.255.255.255

Is the alias entry necessary? Thanks again!

I don't know if the alias entry is necessary, but it is probably the source of your problem. Why are you using the alias entry? Is the DNS for the public IP of the citrix server externally hosts and you want to "doctor" it? Are you doing destination NAT?

shannong
Level 4
Level 4

If the Citrix is on the local subnet with the Pix's interface, then it should not be replying for this obviously. Check inconsistent subnet masks which may cause hosts to think they some devices are on "different" subnets.

BTW...It is common for the first attempt of a ping to fail due to an ARP request to learn the MAC if it wasn't in your host's cache. I would not consider this a symptom of your problem.

jspyker
Level 1
Level 1

Any chance you have used the arp command with the alias option? We ran into this same issue a year ago along with a hit on bug CSCdw57969 which was first fixed in versions 6.2(0.237) and 6.2(0.239). The arp issue has not come back since the removal of the alias option and upgrading to 6.2(2). Hope this helps.

Thank you for your post. We are using static entries for one-to-one nat. Dont we need to use the alias command with that? Thanks.

I am sorry, the alias option I was refering to was the arp command....

ARP INSIDE n.n.n.n hhhh.hhhh.hhhh ALIAS

We were using this form because the firewall was not advertising the mac address of inside to the outside interface. This worked fine until a default changed in a pix release. Then we started seeing inside hosts with bogus arp tables and communications would come to a halt. The servers would starting seeing the pix's mac address for the correct entries. We also tried the sysopt noproxyarp if_name suggestion, but it did not work. We have been running our configs with:

ARP INSIDE n.n.n.n hhhh.hhhh.hhhh

with no problems for about a year.

Thank you everyone for your posts. The problem has been resolved using by adding the config entry "sysopt noproxyarp inside." Thank you again for your time.

Review Cisco Networking products for a $25 gift card