3

The OUTSIDE interface on my firewall appliance is assigned IP address .2

The router it's connected to (ISP) is .1

Keeping in mind Proxy ARP was turned on (don't recall doing that, but it was), I had accidentally mis-configured the interface on my firewall (the .2 device) as 255.255.255.248 instead of .240.

This would limit the range of usable IPs from .0-15 to .0-7

However, all my traffic (and NAT) was done using IPs "less than .7". However, after awhile, if Proxy ARP was turned off, internet connectivity was lost. Turning Proxy ARP back on would provide internet again.

After changing to the subnet on the outside interface to be correct (.240), and turning Proxy ARP off, everything worked as expected.

So everything works - that's great. But why didn't it work even with the wrong subnet, considering I was using all IPs within the misconfigured subnet? The only reason I can think is the IP broadcast address changed, but ARP is Ethernet not IP so a wrong IP broadcast address means nothing.

Anyone have enough insight to what was going wrong, for learning value?

  • After correcting the outside IP's subnet and turning Proxy ARP off, did you clear ARP entries on the router? Has it been longer than 4hours since you did that, and are things still working flawlessly? Because given the way I understand your network to operate, you will still need Proxy ARP enabled for communication to work. – Eddie Nov 16 '14 at 20:09
  • I issued CLEAR ARP - yes. Why 4 hours, and how would I not need Proxy ARP? – user10411 Nov 16 '14 at 20:12
  • Four hours is the default ARP timeout on many Routers. Well, many Cisco routers at least. – Eddie Nov 16 '14 at 20:16
  • Well, I cleared ARP and everything is still working. Why would Proxy ARP be required? – user10411 Nov 16 '14 at 20:34
  • Proxy arp for a NAT might be required, but you can configure that on the NAT statement itself. Using proxy arp just by default is a way to cover misconfigurations and cause weird failure modes sometime in the future. Also was the .1 device trying to broadcast to the .15 broadcast address for its configured subnet, but your firewall was ignoring it because of it's smaller configured subnet? – cpt_fink Nov 16 '14 at 20:50
0

You are correct when you say an ARP request is not addressed to the "Broadcast IP Address" of a particular subnet. So at no time were your ARP "broadcasts" destined to .7 or .15.

Let me try to explain why I said Proxy ARP is required for this to work. Lets assume everything is properly configured, and we'll use the 9.9.9.0/28 network for the example:

Your Firewall owns the IP 9.9.9.2, of the 9.9.9.0/28 network. Your Firewall's default gateway is 9.9.9.1, which is owned by the upstream router. You have three static NAT's configured for servers behind your Firewall, they each own the IP 9.9.9.3, .4, and .5. The server's internal IP addresses are 10.0.0.3, .4, .5, respectively. For this all to work, Proxy ARP must be enabled on your Firewall. Here is why.

Your Firewall (9.9.9.2) can respond to pings. This is because when I ping your Firewall's IP, Routing takes it to the upstream router, who then checks its Route Table and realizes the 9.9.9.0/28 network is directly connected. As a result, it issues an ARP Request for the 9.9.9.2 address, to which your Firewall replies with its MAC address as the 'owner' of the 9.9.9.2 address.

Now if I ping your server, at IP 9.9.9.5, the same Routing will also take it the up-stream router, who will yet again notice that the 9.9.9.0/28 network is directly connected. So the Router issues an ARP Request, looking for the MAC address that 'owns' the IP address 9.9.9.5.

Your server, who is neither on this network or configured for this address, is unable to respond to this ARP Request. Something else must Respond to this ARP on behalf of the server, who is indeed the true owner of this IP. Your Firewall now comes to the rescue, and answers the Up-stream Router's ARP Request with an ARP Response, providing the Firewall's MAC address as the owner of 9.9.9.5. This allows the Router to encapsulate the packet in a way that gets it to the Firewall, who can then forward it to the Server's real address (10.0.0.5).

Without the Firewall issuing a Proxy ARP to respond to the Up-Stream Router's ARP Request, the Router has no way of knowing to send the packet destined to 9.9.9.5 to the Firewall.


I was going to post this initially, but when you said everything is now working with Proxy ARP disabled, I was rather confused. Because in fact, it shouldn't be. Could you post the relevent portion of the Router's "show arp" entries for the Firewall and Server IP addresses? The ones equivalent to the 9.9.9.2, .3, .4, and .5 addresses from my example above.

  • The network stopped working about 6 hours later. I guess ARP took awhile to clear on the ISP's router. Just out of curiosity, is using Proxy ARP like this normal or could I have set things up better? – user10411 Nov 17 '14 at 0:53
  • Ahh and there you have it. The ISP must be using a non-Cisco router, or a Cisco router with the modifying ARP timeout. Sorry you had to experience downtime. Yes, Proxy ARP is normal. Any device that does NAT, must be able to Proxy ARP in order to NAT successfully. – Eddie Nov 17 '14 at 0:56
  • Gladly. If your question was fully answered, please mark the response as the answer. If I left something out that you still weren't sure about, please let me know. – Eddie Nov 17 '14 at 1:01
  • One final question: If I had a host directly attached to that interface that used .5, wouldn't Proxy ARP and the actual device respond to the ARP for .5? – user10411 Nov 17 '14 at 1:07
  • Assuming you meant 9.9.9.5, and not 10.0.0.5, then Yes -- the Firewall would Proxy ARP for the address and the Host would (regular) ARP for the address. You would effectively have an IP conflict. Remember, what is causing the Firewall to Proxy ARP is not that the host exists behind its interface, its that you have a NAT statement configured for that address. So if a host were connected to the outside Network, and you also had a Static NAT statement, you would have two entities providing two different MAC addresses in response to an ARP Request. – Eddie Nov 17 '14 at 1:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.