Forum Discussion
Bill_Hoffman_11
Nimbostratus
NimbostratusProxy ARP Issues with FirePass v6.01
Anyone have any issues with Proxy ARP being enabled with FirePass v6.01? It would be interesting to hear if anyone is having any problems with this. We have setup two separate ingresses and egresses so that we can have separate portals to allow for segmentation of our un-trusted off-shore vendor traffic from our trusted employee traffic. The un-trusted egress is connected to our partner DMZ, and the trusted egress is connected to another network segment. The partner DMZ is separated from our core network by a pix firewall, and the trusted egress is also connected to the same core network as the pix. It appears that if an ARP request is submitted for the un-trusted internal egress on the FirePass device that the trusted internal egress responds and proxys the un-trusted egresses address.
OwenH_68783I can't tell from the details you posted, but are you sure it's the Firepass doing the proxy-arp? I've had many problems with PIX proxy arp'ing in scenarios where two machines are on the same PIX interface and both have static translations. When they try to talk to each other, the PIX responds with it's MAC. If you're translating the Firepass on the PIX (and I would assume you are), then you might need to hard code the arp table entries for it in the PIX.
arp dmz2 192.168.202.246 00e0.b603.64f3 alias
Bill_Hoffman_11I have been working with F5's technical support, to help them reproduce the problem that we have been seeing. They were ultimately able to reproduce it thanks to one of their technicians who stuck with us. They will resolve the issue in the next cumulative hotfix for 5.5.2. a description of the Linux kernal option that is causing the problem is documented below.
As discussed, the most concise explanation that I could find about the option that was changed is at the following URL:
http://blog.nominet.org.uk/tech/2006/12/08/arp_announce/
We set the arp_announce option to 1, which forces ARP request packets to use the IP address from the same subnet as their target address as their Source Protocol Address if the ARPing device has such an IP on the interface that the ARP packets exit from. What will happen now is that when the FirePass ARPs for the core router's address, it will use the ip address of the interface that the ARP packet is sent from as the Source Protocol Address within the ARP packet. In your case, this IP will be the FirePass IP for the "trusted" network. When the core router receives this ARP request, it will update it's ARP table with the FirePass "trusted" IP address and associated MAC address. This IP will be on the same subnet as the core router IP address, whereas before it was not.
Please let me know if you need any further clarification. As discussed, I will let you know as soon as the next cumulative hotfix for 5.5.2 is released, which will contain the change above. This change is tracked as CR84406.