Proxy ARP Issues with FirePass v6.01

I 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.