04-13-2010 12:19 PM - edited 03-11-2019 10:32 AM
I've been fighting an issue for months where my other offices haven't been able to reach our internal web portal sporadically. I haven't had time to devote to the issue, because it was sporadic and I always had something else that took a higher priority any time the issue came up. After a particularly obnoxious few days with the issue, it got bumped up higher on the priority list and I got to devote time to it. After a lot of digging around I found the issue came down to incorrect MAC entries being sent out in response to ARP requests. It appears my firewall is answering ARP requests with its MAC for requests that are going to my router. The MPLS router is the default gateway for my network, and it passes traffic that isn't bound for the outside offices to the firewall to pass on to the internet.
So, after some reading I think my NATing is causing the firewall to answer ARP requests for my router and messing up my clients' ARP tables. I read about similar problems on this forum and there was discussion talking about ARP proxy being set by default and causing the behavior. There was a command for disabling ARP proxy, but I didn't want to toss it on my firewall without clearly understanding what it would do as I don't want to break my NATing. Anyone able to help me out and give me a broad overview of what happens when you issue the "sysopt noproxyarp Inside" command?
04-13-2010 01:35 PM
sysopt proxyarp on an interface allows the firewall to respond to arp requests for addresses that are not actually assigned to an interface on the firewall.
static (inside,outside) 195.17.17.10 192.168.5.1 netmask 255.255.255.255
the above means that if a device on the outside of the firewall arps for 195.17.17.10 then the firewall will respond with the mac-address of it's outside interface. The packet will then be sent to the firewall and it will NAT the destination IP from 195.17.17.10 to 192.168.5.1
So for the majority of firewalls you would expect to have sysopt proxyarp enabled on the outside interface because it is common for internal private addresses to be presented to the outside as public IP addresses.
The inside interface is a different matter. It is not as common to need it on the inside interface because you don't often have these sort of statements -
static (outside,inside) 10.228.53.6 192.168.10.1 netmask 255.255.255.255
the above means that from the inside if a device arps out for 10.228.53.6 then the firewall will respond with the mac-address of it's internal interface. The packet will be sent to the firewall and it will NAT the destination IP from 10.228.53.6 to 192.168.10.1. These sort of statics are not very common on the firewall.
So what you need to do is check your config and see if there are any NAT statements that require the firewall to respond for addresses on it's internal interface.
Jon
04-13-2010 02:33 PM
All right, I've gone back to my config and grabbed the relevant config lines:
global (outside) 1 x.x.143.35 netmask 255.255.255.224
global (inside) 2 10.3.58.9 netmask 255.255.255.0
nat (outside) 0 access-list outside_nat0_outbound
nat (outside) 0 access-list outside_nat0_outbound_1 outside
nat (inside) 0 access-list Inside-NoNat
nat (inside) 0 access-list inside_nat0_outbound_1 outside
nat (inside) 1 0.0.0.0 0.0.0.0
nat (DMZ) 0 access-list DMZ-NoNat
nat (DMZ) 0 access-list DMZ_nat0_outbound outside
nat (DMZ) 1 0.0.0.0 0.0.0.0
static (DMZ,outside) x.x.143.40 172.16.100.3 netmask 255.255.255.255
static (inside,outside) x.x.143.37 10.3.58.13 netmask 255.255.255.255
static (inside,outside) x.x.143.42 10.3.58.250 netmask 255.255.255.255
static (DMZ,outside) x.x.143.38 172.16.100.4 netmask 255.255.255.255
static (inside,outside) x.x.143.56 10.3.58.253 netmask 255.255.255.255
static (DMZ,outside) x.x.143.46 172.16.100.7 netmask 255.255.255.255
static (inside,outside) x.x.143.45 10.3.58.28 netmask 255.255.255.255
static (DMZ,outside) x.x.143.50 172.16.100.13 netmask 255.255.255.255
static (DMZ,outside) x.x.143.49 172.16.100.14 netmask 255.255.255.255
static (DMZ,outside) x.x.143.55 172.16.100.10 netmask 255.255.255.255
static (inside,outside) x.x.143.48 10.3.58.147 netmask 255.255.255.255
static (inside,outside) x.x.143.52 10.3.58.149 netmask 255.255.255.255
static (inside,outside) x.x.143.57 10.3.58.252 netmask 255.255.255.255
static (inside,outside) x.x.143.59 10.3.58.171 netmask 255.255.255.255
static (inside,outside) x.x.143.53 10.3.58.77 netmask 255.255.255.255
static (inside,outside) x.x.143.54 10.3.58.22 netmask 255.255.255.255
static (inside,outside) x.x.143.41 10.3.58.63 netmask 255.255.255.255
static (inside,outside) x.x.143.58 10.3.58.141 netmask 255.255.255.255
static (inside,outside) x.x.143.44 10.3.58.80 netmask 255.255.255.255
static (inside,outside) x.x.143.43 10.3.58.31 netmask 255.255.255.255
static (inside,outside) x.x.143.39 10.3.58.125 netmask 255.255.255.255
static (inside,outside) x.x.143.47 10.4.58.85 netmask 255.255.255.255
All of my static mappings look correct to be ARPing for the outside addresses only, as far as I can see. Since my static mappings don't appear to be an issue, that leaves me wondering about my nat statements. I can slap on the "sysopt noproxyarp Inside" after hours to experiment a bit, I just want a better understanding of what's going to happen before I work with it. That I can think of, I don't think I want my firewall doing any ARP proxying on addresses on the inside interface. I'm just trying to think if there would be any legitimate reason that I may be overlooking.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide