PIX: "sysopt noproxyarp" disables ARP for static/global IPs?
John Caruso
PIX docs aren't very informative about what this causes the PIX to do
("The sysopt noproxyarp command allows you to disable proxy-arps on a
PIX Firewall interface"; thanks, couldn't have figured that out...), and
I was a little suspicious that it was going to stop ARP'ing for its own
static and/or global addresses in addition to stopping proxy ARP.
Sure enough, when the ARP entry for one of the PIX static NAT addresses
timed out on the router, the PIX did *not* respond to subsequent ARPs for
that static address. I was able to reproduce this behavior easily by
clearing the ARP cache on the router. This is what the router's ARP
entry for the PIX static address looked like:
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.1.1.100 0 Incomplete ARPA FastEthernet0/0
When I reenabled proxy ARP on that PIX interface, the router was again
able to talk to the static address on the PIX (and the ARP entry on the
router was filled in correctly, of course). I tested it with a global
address as well and saw the same behavior--with "sysopt noproxyarp" in
place, the only thing the PIX will still ARP for is its own interface
address. So apparently if you disable proxy ARP on a PIX interface,
you are also effectively disabling ARP for any static or global NAT/PAT
addresses defined on that interface (!?!).
Am I missing something here? I'm having a tough time believing that
this is intended behavior; it means that "sysopt noproxyarp" is unusable
unless you have absolutely no static or global addresses defined on the
target interface. At the bare minimum--assuming it's not a bug--this
behavior should be mentioned in the PIX docs, since it can be extremely
dangerous and cause problems that are difficult to track down (since
everything will appear to be fine until ARP cache entries start timing
out on various devices in the network).
I can see an argument that ARP'ing for static/global addresses is in
fact proxy ARP (that's what made me suspect this might happen in the
first place), but c'mon, Cisco--these addresses are *explicitly* defined
in the config, not learned via ARP on another interface. I can't think
of any plausible situation in which this (apparent) behavior is desirable,
but it's clearly desirable at times to be able to turn off proxy ARP on
an interface that has statics and/or globals.
- John
Root
I have no explanation to your case, I have also disabled proxy-arp on time
because
when proxy-arp was enabled, the local network stopped working correcly (the
clients were unabled to communicate to the servers).
Why ?
Bye
Michael Janke
> I recently had reason to disable proxy ARP on a PIX running 6.2(1). The
> PIX docs aren't very informative about what this causes the PIX to do
> ("The sysopt noproxyarp command allows you to disable proxy-arps on a
> PIX Firewall interface"; thanks, couldn't have figured that out...), and
> I was a little suspicious that it was going to stop ARP'ing for its own
> static and/or global addresses in addition to stopping proxy ARP.
>
> - John
We have dozens of PIX's deployed with noproxyarp & absolutely no problems of the type you are describing.
Which interfaces are disabled & where is the router?
--
-----------------------------------------
Michael Janke
Director, Network Services
Minnesota State Colleges and Universities
-----------------------------------------
John Caruso
>We have dozens of PIX's deployed with noproxyarp & absolutely no problems of the type you are describing.
Interesting. Which PIX software release? And on which interface(s) is
proxy ARP disabled?
>Which interfaces are disabled & where is the router?
I've tested it on two PIXes, a 515 and a 520, both of which had just an
outside and inside interface. The problem occurs when I disable proxy
ARP on the outside interface (which is where the static and global NAT/PAT
addresses live). It may occur on other interfaces as well but I haven't
tested that yet. The router interface and the PIX's outside interface
are connected via a shared VLAN on a Cat2924XL--nothing fancy. The PIX's
inside interface is attached to a different 2924XL. The routers in the
tests were a Cisco 3640 and a Cisco 3660.
The relevant PIX config is as follows:
ip address outside 10.1.1.70 255.255.255.192
global (outside) 1 10.1.1.69 netmask 255.255.255.192
static (inside,outside) 10.1.1.100 172.22.22.22 netmask 255.255.255.255 0 1
000
With this config in place, the router's ARP table looks like this (the
router's own IP address is 10.1.1.65):
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.1.1.100 199 00d0.b783.fe61 ARPA FastEthernet0/0
Internet 10.1.1.69 2 00d0.b783.fe61 ARPA FastEthernet0/0
Internet 10.1.1.70 0 00d0.b783.fe61 ARPA FastEthernet0/0
Internet 10.1.1.65 - 0009.7cb9.50e0 ARPA FastEthernet0/0
As expected, the addresses defined in the static and global commands (i.e.
10.1.1.100 and 10.1.1.69) are present in the ARP table. However, if I add
"sysopt noproxyarp outside" to the config and then clear the router's ARP
cache, this is what the ARP table looks like afterward:
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.1.1.100 0 Incomplete ARPA FastEthernet0/0
Internet 10.1.1.69 0 Incomplete ARPA FastEthernet0/0
Internet 10.1.1.70 0 00d0.b783.fe61 ARPA FastEthernet0/0
Internet 10.1.1.65 - 0009.7cb9.50e0 ARPA FastEthernet0/0
10.1.1.70 (the PIX's interface address) is still present, but the static
NAT address and the global PAT address are now shown with a Hardware Addr
of "Incomplete". In other words, the PIX has stopped replying to the
router's ARP requests for these addresses. Removing the "sysopt noproxyarp
outside" from the config makes everything work as it should again.
I've placed a call with Cisco about this.
- John
Michael Janke
> In article <3D0FF610...@attbi.com>, Michael Janke wrote:
>
>>We have dozens of PIX's deployed with noproxyarp & absolutely no problems of the type you are describing.
>
>
> Interesting. Which PIX software release? And on which interface(s) is
> proxy ARP disabled?
>
>
>>Which interfaces are disabled & where is the router?
>
>
> I've placed a call with Cisco about this.
>
> - John
We have it disabled on the inside, not the outside. We have multiple subnets & no inside routers at a bunch of sites, so both inside & DMZ are on the same LAN, but with different IP networks. We need noproxyarp to keep both interfaces from answering the same arp's.
If the number of IP 's that are static'd is small, could you config static arp's entries in the router?
-- Mike
John Caruso
> We have it disabled on the inside, not the outside. We have multiple
> subnets & no inside routers at a bunch of sites, so both inside & DMZ
> are on the same LAN, but with different IP networks. We need noproxyarp
> to keep both interfaces from answering the same arp's.
That's similar to the situation that led me to disable proxy ARP as well.
But since I didn't want my PIX proxy ARP'ing at all, I turned it off on
all interfaces, not realizing that "turn off proxy ARP" also means "don't
bother ARP'ing your own static and global IPs." I've now verified from
Cisco that this is, in fact, the *designed* behavior (!?!). I would
imagine this applies to all interfaces, but I haven't testedit on
anything other than outside.
The Cisco rep I spoke to agreed that this makes no sense, since the IP
addresses in static/global commands are in effect "owned" by the PIX
and so the PIX should always respond to ARP requests for them. At the
least, Cisco will be posting documentation to this effect on the website,
and they might go so far as to amend the PIX documentation itself to
include a warning about this, but I'd say the chances of them actually
fixing this stupid bug are slim to none.
So if you ever consider using "sysopt noproxyarp", beware--it does NOT
just turn off proxy ARP, despite the name.
- John
fmer...@triad.rr.com
I find it a bit dificult to believe that this is true. If the PIX
doesn't respond to any ARP on a given interface, then what's the point
in even having the interface? If another device attached to the
interface can't resolve the physical address, then nothing is going
anywhere through that interface (unless some other mapping is done on
that other device since he won't get a response to an ARP per this!).
There would be little to no value in having the command at all if it
disabled all ARP replies.
(Am I way off here?!!)
I would gues that the truth is is that it disables Proxy only.
I don't have one I can test it with though, so take it for what it's
worth.
Good Luck!
John Caruso
>>The Cisco rep I spoke to agreed that this makes no sense, since the IP
>>addresses in static/global commands are in effect "owned" by the PIX
>>and so the PIX should always respond to ARP requests for them. At the
>>least, Cisco will be posting documentation to this effect on the website,
>>and they might go so far as to amend the PIX documentation itself to
>>include a warning about this, but I'd say the chances of them actually
>>fixing this stupid bug are slim to none.
>>
>>So if you ever consider using "sysopt noproxyarp", beware--it does NOT
>>just turn off proxy ARP, despite the name.
>
>doesn't respond to any ARP on a given interface, then what's the point
>in even having the interface?
You may not have read the previous postings: the PIX *does* continue to
respond to ARPs for its own interface address. It's just that it stops
responding to ARPs for global and static IP addresses defined on that
interface. So your static mappings all become useless, and your global
IPs all break (unless you're using the interface address for your global,
in which case it will continue to work).
As I said, this is verified--I've tested it on 6.1(1) and 6.2(1), and
Cisco even said they're doing it by design(!!). I'm as astonished as you
are, but there it is. Try it yourself and see--add "sysopt noproxyarp
outside" to your config, and then clear the ARP caches on other devices
on your outside network, and see what happens to your static and global
IPs. I dare you :-). Just don't do it on an active network.
>There would be little to no value in having the command at all if it
>disabled all ARP replies.
>(Am I way off here?!!)
Just slightly, as I said, since it does still reply to ARPs for its own
interface address. But I agree that it reduces the command to having
little or no value. And it's a bitch of a problem to troubleshoot, too,
because you may not see the failure until hours after you make the change
(after various ARP caches start timing out). And good luck figuring out
why the brand new static IP you added in your DMZ doesn't work, just
because you turned off proxy ARP on that interface months ago....
I'm surprised nobody's run into this in the past, but I'm guessing that
most people just turn off proxy ARP on the inside interface.
- John
John Caruso
>>>So if you ever consider using "sysopt noproxyarp", beware--it does NOT
>>>just turn off proxy ARP, despite the name.
In fact, according to Cisco, the PIX doesn't do what the rest of us know
as "proxy ARP" at all, ever (i.e. proxy ARP as discussed in RFC 1027).
So "sysopt noproxyarp" is just a highly misleading name for the command,
and the PIX documentation is simply incorrect when it says that "sysopt
noproxyarp" turns off proxy ARP.
What "sysopt noproxyarp" actually does, according to Cisco tech support,
is to turn off ARP replies for statics, globals, and NAT 0. It has not
a thing to do with actual proxy ARP.
Cisco has decided that this is a documentation bug and they say they're
going to update the PIX docs to address it. The bugID is CSCdx92079 (it
hasn't shown up on the web yet).
- John
Dana J. Dawson
Well, I think it's a matter of semantics as to whether the PIX really is doing proxy
ARP or not. In the sense that responding to an ARP request when the IP isn't really
assigned to your own physical interface is a flavor of proxy ARP, then you could
consider the PIX behavior to be proxy arp.
Back to the real issue, I have seen circumstances where you really do need this
feature -- usually when the subnetting is not set up optimally and you want to
disable NAT between a pair of interfaces with a "network static". For example,
suppose you're using 10.x.x.x addresses on the inside interface and have a whole
slew of subnets out that interface. Let's also suppose that you have a DMZ
interface and are using one of the 10.x.x.x subnets there, too, and you don't want
to do NAT between the Inside and the DMZ, but you do want to do NAT between the
Inside and Outside. The easy way to do this is to use static NAT between the Inside
and DMZ to NAT the inside 10.x.x.x addresses to themselves (in the newer PIX
software you could also use a "nat (inside) 0 access-list" command to selectively
disable NAT). Now you could do these static NAT statements one subnet at a time,
but if you have hundreds of subnets, the easy way to do it is with a single "static
(inside,DMZ) 10.0.0.0 10.0.0.0 netmask 255.0.0.0" command. The only problem with
this is that now the PIX will proxy arp for *EVERY* 10.x.x.x address, including the
subnet assigned to the DMZ interface, which you probably don't want depending on
what else is on the DMZ subnet. The "sysopt noproxyarp" command is just the ticket
in this case.
HTH
Dana
--
Dana J. Dawson
Senior Staff Engineer CCIE #1937
Qwest Global Services (612) 664-3364
Qwest Communications (612) 664-4779 (FAX)
600 Stinson Blvd., Suite 1S
Minneapolis MN 55413-2620
"Hard is where the money is."
John Caruso
>> What "sysopt noproxyarp" actually does, according to Cisco tech support,
>> is to turn off ARP replies for statics, globals, and NAT 0. It has not
>> a thing to do with actual proxy ARP.
>>
>> Cisco has decided that this is a documentation bug and they say they're
>> going to update the PIX docs to address it. The bugID is CSCdx92079 (it
>> hasn't shown up on the web yet).
>
> really is doing proxy ARP or not. In the sense that responding to
> an ARP request when the IP isn't really assigned to your own physical
> interface is a flavor of proxy ARP, then you could consider the PIX
> behavior to be proxy arp.
In the case of a simple static or global with no NAT 0, though, the
IP address is in fact assigned to the PIX--even though it's a proxy
address for another device. So what the PIX is really doing is ARP
for a proxy address (or addresses), which isn't quite the same thing
as proxy ARP. And if you read the RFC it's pretty clear that the PIX
isn't doing proxy ARP (or that if you call what it does do "proxy ARP",
it's violating the RFC...).
Cisco more or less agreed about this and agreed that the command name
was poorly chosen. Much better/safer/more flexible would have been a
few commands like:
sysopt nostaticarp
sysopt noglobalarp
...which is of course what the current command actually does. Luckily,
they'll be updating the docs to clear up the confusion.
I'd agree that it's an unimportant semantic issue if it hadn't cost me
an hour or so of network downtime and/or instability. :-)
> Back to the real issue, I have seen circumstances where you really
> do need this feature -- usually when the subnetting is not set up
> optimally and you want to disable NAT between a pair of interfaces
> with a "network static".
Thanks for the example--it does show that the designed behavior is
useful in certain circumstances. I'm curious: when you've used that
methodology (assuming it wasn't just presented as illustration), have
you then had to use static routes to the PIX interface address on your
routers (et al) for statics or globals for which you *did* still need
ARP replies from the PIX? This was Cisco's suggested workaround, which
seems like it should work, but I'd be surprised if people in the field
were actually working around "sysopt noproxyarp"'s potentially undesirable
side effects in that way....
- John
Dana J. Dawson
> [snip]
> > Back to the real issue, I have seen circumstances where you really
> > do need this feature -- usually when the subnetting is not set up
> > optimally and you want to disable NAT between a pair of interfaces
> > with a "network static".
>
> Thanks for the example--it does show that the designed behavior is
> useful in certain circumstances. I'm curious: when you've used that
> methodology (assuming it wasn't just presented as illustration), have
> you then had to use static routes to the PIX interface address on your
> routers (et al) for statics or globals for which you *did* still need
> ARP replies from the PIX? This was Cisco's suggested workaround, which
> seems like it should work, but I'd be surprised if people in the field
> were actually working around "sysopt noproxyarp"'s potentially undesirable
> side effects in that way....
>
> - John
Yes, you sometimes do need to add a static route to the PIX to maintain
connectivity, but more often the overlapping subnets are between the inside and
DMZ interfaces and the default route is good enough. This situation is
effectively the same as if the global address range is from a non-connected
network, since you always need a static route for that case. I used to see a
lot of configs that were like that, but, for some reason, they're much less
common now. It's never seemed like a big deal to me, but now that you mention
it, it is an easy thing to forget to do and has caused a lot of frustration to a
lot of people.
Dana
--
Dana J. Dawson djd...@qwest.com