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?
Solved! Go to Solution.
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?
Our PIX is running 6.1(2). An example static entry:
static (inside,outside) 220.127.116.11 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 18.104.22.168 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?
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.
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.
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.