Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1552
  • Last Modified:

PIX 525 Proxy ARP questions

To all:
We have a PIX 525 in a failover environment. We have another appliance called a Packetshaper model 7500 that we are attempting to install. This appliance is a QOS/bandwidth prioritization appliance. What is happening is our firewall interfaces have proxy ARP enabled. The engineer from Packetshaper indicated that what is happening is the PIX is responding to ARP requests on various interfaces which in turn is interfering with the management capabilities of the Packetshaper. I do not want to turn any of this off before getting some expert opinion from someone as to what ramifications turning this off may have. We are running in a NAT environment with ACL’s on the firewall.  Since it seems that proxy ARP can be removed from particular interfaces, I would imagine that we are looking to turn this off (if possible) on our inside and dmz1 interfaces. These are the networks where this appliance will be visible through. I have emailed Cisco as well however I wanted to see if anyone had any idea about this.

Thank you
0
FlaglerCollege
Asked:
FlaglerCollege
  • 10
  • 9
  • 4
2 Solutions
 
Keith AlabasterCommented:
Are you using ip's on these interfaces other than those assigned to the physical interfaces themselves? ie do any of the interfaces have logical ip's assigned to them as well? How is the failover operating, direct-connect cables on other interfaces?
0
 
Keith AlabasterCommented:
In your config do you have a reference to 'sysopt noproxarp'?
0
 
FlaglerCollegeAuthor Commented:
No, no logical IP addresses. The failover is direct cable and each interface has it's own VLAN to facilitate the failover. Meaning e0 on PIX1 & E0 on PIX2 goes into one VLAN with the 3rd connection on the switch (on the same VLAN) going to its destined network location. Does this help? Thank you for your assistance!!!
0
A Cyber Security RX to Protect Your Organization

Join us on December 13th for a webinar to learn how medical providers can defend against malware with a cyber security "Rx" that supports a healthy technology adoption plan for every healthcare organization.

 
FlaglerCollegeAuthor Commented:
I have saved the running configuration off of the firewall and searched for this syntax and it is not present in the configuration.
0
 
Keith AlabasterCommented:
when you perform a sh conf, what version OS is it running? 6.x or 7?
0
 
FlaglerCollegeAuthor Commented:
Cisco PIX Firewall Version 6.3(3)
Cisco PIX Device Manager Version 3.0(4)
0
 
Keith AlabasterCommented:
Can you try

conf t
sysopt noproxyarp inside (or whatever the interface is called)
sysopt noproxyarp dmz (or whatever the interface is called)

See if this helps before you save the config.
0
 
FlaglerCollegeAuthor Commented:
Keith thank you for your help! I do have a TAC case open with Cisco however do you feel that there are any network ramifications to making these changes? I am not looking to hold anything to anyone however I was just curious if you happen to know if there were and issues with making this type of change?
0
 
Keith AlabasterCommented:
I understand. The only ramification I am aware of is that the interface will not not respond to other (aliased) IP addresses. for example if you had a .252 mask assigned allowing the interface to respond to two ip addresses then the interface will not respond to arp requests for the 2nd ip address. I don't use it on my external interfaces as it needs to respond to 14 different ip addresses; one on the physical interface plus 13 others which I use with static translations. i use it always for my internal interfaces.

regards
keith
0
 
FlaglerCollegeAuthor Commented:
Again Keith thank you. We do not use IP aliasing on our PIX. I truthfully didn't even know it did that. Each interface has its own address. We have NAT adresses tied to our outside interface. We do use static IP translations to our inside/outside or inside/dmz interfaces etc. So it really sounds like this is going to be a safe bet. When I get in tomorrow I will try it on an interface. I am used to makeing changs on the PIX however this one does make me a little nervous ;)

I appreciate your help and will be in touch tomorrow.
0
 
Keith AlabasterCommented:
I would have hoped that one of my colleagues would have either conrfimed this for you also or shot me down in flames for being totally wrong but ho-hum.
0
 
lrmooreCommented:
Keith has you covered, but I just wanted to re-assure you that disabling proxy arp from the inside interface will not affect any outbound traffic.
Just don't disable it on the outside interface or all your nat's will quit working.
As a general rule of thumb, I always disable proxy arp on the inside interface.
0
 
FlaglerCollegeAuthor Commented:
Excellent and I appreciate both of your expertise on this. I will console into the PIX in a little bit and turn this off on the inside and dmz (dorm) interfaces. One other question just to make sure.. I have some static (inside,outside), static (dmz,outside) & static (inside,dmz) addresses in place. No chance that this change will disrupt this as well? This is to permit certian services from the outside to the inside or to the dmz and would not assume so however I just wanted to make sure... You know "leave no stone unturned" ;)


Brendan
0
 
lrmooreCommented:
No problem with disabling inside, you might want to hold off on disabling it on dmz.
Is the packet shaper on the inside, or on the dmz, or in front of the PIX?
0
 
FlaglerCollegeAuthor Commented:
The PS will listen/shape on the inside and dmz1 (dorm) interfaces... But truthfully I was not accurate in my previous post. The dorms are on interface "dmz1" and not "dmz" the only reason I mention this is I do have different static entries for this interface:
static (dmz1,outside)
static (inside,dmz1)
static (dmz,dmz1)
static (inside,dmz1)

Hope this can clairfy things a little.... There is one service on this network that is accessable from the outside which is our streaming media server for our raido station. That may get knocked out with the change..?

Thank you
0
 
lrmooreCommented:
I think you may need to leave it on dmz1 for the time being.
There is potential for disruption of traffic between dmz1 and inside and dmz/dmz1, but easy enough to fix - just re enable proxy arp on that interface.
Inside should not be a problem at all, just be careful on the others and do 1 at a time and verify results.
Take baby steps is all I'm saying..
0
 
FlaglerCollegeAuthor Commented:
Will do and I appreciate your thoughts on this... I will try this today and let you know my findings.
0
 
Keith AlabasterCommented:
Thanks Les. :)
0
 
FlaglerCollegeAuthor Commented:
Well, I have a work around with the appliance as the PIX can't be altered in our current configuration. This does not mean that what you recommended would not work. It simply means that we have quite a few static translations that would not work if this command was implemented. Here is the communication from Cisco regarding the sysopt noproxyarp command in our configuration:


*****
Hi ,

As per the case notes it seems that the packet shaper is getting affected with the proxyarp feature of the firewall

By default, the PIX Firewall responds to ARP requests directed at the PIX Firewall's interface IP addresses as well as to ARP requests for any static or global address defined on the PIX Firewall interface (which are proxy ARP requests).Consequently, if you use the sysopt noproxyarp if_name command, the PIX Firewall no longer responds to ARP requests for the addresses in the static, global.

The command would stop all kind of translations which involve the interface on which we have initiated the sysopt noproxyarp command.

eg. sysopt noproxyarp dmz

Then any kind of translation done by that interface would cease to work.

Like static (inside,dmz) translation will not work as the dmz interface would not be ableto provide its mac address for inside ip addresses.


static (dmz,outside) will work because in this case the mac address would be advertised my outside interface and not the dmz interface.


This command would have the same effect for host as well as network static translations.In our case i can see we have lot of self static implemented in the firewall and which can be effected by implementing the sysopt noproxyarp commands

****
So in light of this I cant use this command but again wanted to thank you for your time and expertise on this. I have certianly learned from this and again thank you both for your time.

Sincerely,
Brendan
0
 
Keith AlabasterCommented:
Thanks for the points Brendan. Not quite sure what the options are then if Cisco agrees that the proxyarp is the issue but your circumstances don't allow for its removal. Only thing that comes to mind is to route the traffic between the inside and the DMZ rather than use statics for translation and put a route on the inside so that the clients etc know how to get there but not sure if that would be feasible for you. ie they keep their true IP addresses
0
 
FlaglerCollegeAuthor Commented:
Agreed... I shared some of this with Cisco and I was basically told that this is how the device responds to various requests and is "by design". Alas a workaround with the arp "forced resolution" command with the packshaper (they call it "privadd") and some valueable inforamation learned. Since we are a college, others were faced with this similiar situation with PIX firewalls. So today we were able to help others and make a difference.

Thanks again :)
0
 
Keith AlabasterCommented:
Welcome and good luck :)
0
 
lrmooreCommented:
Thanks for the update!
- Cheers!
0

Featured Post

NFR key for Veeam Agent for Linux

Veeam is happy to provide a free NFR license for one year.  It allows for the non‑production use and valid for five workstations and two servers. Veeam Agent for Linux is a simple backup tool for your Linux installations, both on‑premises and in the public cloud.

  • 10
  • 9
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now