Clarification on ASA

[Federico Coto Fajardo]

Hi,

Just a clarification on Proxy ARP on ASAs.

Scenario:

Web Server 10.1.1.1 -- in ----  ASA ---- out ----- Internet

Let's say the WWW server has real IP 10.1.1.1 and static NAT 200.1.1.2

ASA's outside IP is 200.1.1.1

When traffic comes from the Internet to the NAT'ed IP of the Web Server (200.1.1.2), the ASA has to respond with it's own MAC (Proxy ARP).

If disabling Proxy ARP on the outside interface, then traffic will never reach the Web Server from the Internet (unless there's a static ARP entry in the Gateway pointing to the ASA's outside interface).

Same thing happens with dynamic NAT.

Bottom line:

1. Can't disable Proxy ARP on ASA if using NAT (to present itself as another IP to another interface), unless there's a static ARP entry on the Next Hop.
2. Can safely disable Proxy ARP on the inside interface (unless there's NAT to present the inside network as something else to another interface)?

I am looking to understand this correctly.

Thank you very much,

Federico.

[Jouni Forss]

Hi,

To my understanding the situation is the following

If you have Proxy ARP disabled on the WAN interface then only WAN interface IP address related ARP requests are answered. ASA wont reply to any ARP request made related to the IP address that different from the IP address of the actual interface on the ASA.

With regards to the "inside" interface Proxy ARP I would imagine that the only situation you might need Proxy ARP on it would be if you are Dynamic PAT/NATing or Static NATing something to an IP address belonging to the "inside" interfaces subnet from behind some other interfaces.

Traffic coming to any other destination subnet/IP from behind "inside" interface would naturally be routed to the interface and no ARP Requests would be used by the device behind "inside" interface since the destination is not from its network. (other than to determine the GW MAC address of the GW IP which would naturally be the ASA interface which should reply even if the Proxy ARP was disabled on the "inside" interface)

Atleasts thats how I understand it.

- Jouni

[Jouni Forss]

And I guess if you wanted to host a Web server with Proxy ARP disabled you could always use the "interface" IP address of the external interface with Static PAT which would enable the connections to work to the server.

I guess the same would apply if you were to PAT something towards the "inside" using the "interface" IP address of "inside".

- Jouni

[Federico Coto Fajardo]

Thank you Jouni,

The reason I ask is because I have a situation with some ASAs that have around 20 or more interfaces, and to make it interesting they all have dynamic and/or static NAT rules to every other interface.

So I'm trying to understand on which interfaces can I disable Proxy ARP safely without any problems.

Federico.

[Federico Coto Fajardo]

I may add that the reason I'm looking to disable Proxy ARP from the interfaces is because the ASA seems to be under a great deal of ARP traffic that is causing network response problems. A lot of that traffic is unnecesary traffic.

Disabling Proxy ARP will not resolve the underlying problem, but might free the ASA a bit of resources (not having to Proxy ARP when not needed).

Federico.

[Jouni Forss]

Hi,

Is the ASA then connected directly to some L2 network wihtout routing devices between the actual users and the ASA interface?

- Jouni

[Federico Coto Fajardo]

Jouni, yes and no :-)

Some interfaces are connected to the L2 network with no L3 devices between users and ASA.

Other interfaces do have a L3 device routing traffic.

All interfaces have static NATs (also dynamic NAT) between each other.

The problem is the ASA hangs at certain periods of time causing network disruption and we have narrowed it down to many ARP traffic hitting the ASA on almost all interfaces. The ASA won't failover to the other unit, but won't even respond to the console when the problem occurs.

So, we think that one solution was to free the ASA from doing Proxy ARP when not needed, and see if that saves us from impacting the ASA so much with the ARP traffic.

Federico.

[Jouni Forss]

Hi,

Can't say I have ever troubleshooted a situation where the amount of ARP would have caused a problem with the device operation. Most larger networks are never setup directly to a switched network but rather a core router/switch.

Is usually more common that I have to determine why ARP isnt getting through some device.

I wonder if doing a ARP capture on the firewall would help determine the source of problem more closely or have you tried it?

capture LAN-ARP ethernet-type arp interface

Or would this just add to the problem while active.

When I look at my own ASAs ARP capture on the WAN interface I can see constant ARP requests for different IP address MAC. Mostly since I have 2x /29 public subnets for testing purposes at home. Good to work for the ISP

- Jouni

[Federico Coto Fajardo]

You're right. We have some underlying design problems and that's causing lots of problems on this network.

There is work been done to correct them all and avoid having this problem in the first place.

But... in the meantime, I want to understand what criteria should I consider to find out if I can safely remove Proxy ARP on a specific interface on the ASA or not. If there are static NAT's on that interface or dynamic (translating to different addresses besides the ASA's interface IP), Proxy ARP cannot be disabled?

Thanks,

[Jouni Forss]

Hi,

To my understanding the only situation where you need the Proxy ARP enabled on an ASA interface if NAT/PAT is performed to an IP address belonging to the subnet of that interface but the IP address is NOT the IP address of that interface

For example

interface GigabitEthernet0/0

nameif LAN

security-level 100

ip address 10.10.10.1 255.255.255.0

interface GigabitEthernet0/1

nameif DMZ

security-level 50

ip add 192.168.10.1 255.255.255.0

global (LAN) 1 10.10.10.100

nat (DMZ) 1 192.168.10.0 255.255.255.0

To my understanding the above configurations would required that interface "LAN" has Proxy ARP enabled as any traffic coming towards the IP address 10.10.10.100 would result a device in the network 10.10.10.0/24 first sending an ARP to determine the MAC address of that IP address.

However if the configurations was only

global (LAN) 1 interface

nat (DMZ) 1 192.168.10.0 255.255.255.0

Then interface LAN would not require Proxy ARP enabled as the interface IP address would be the only IP address which MAC address should be determined by the hosts behind LAN and the ASA would answer to this normally as it holds the IP address in its actual interface.

Most of the environments we deal with nowadays are already running 8.3+ software levels and generaly only have Dynamic PAT/NAT towards external interface and have Proxy ARP enabled. Rest of the interfaces dont have any NAT configured between them and have their Proxy ARP disabled.

Then again your configuration might be totally different to what I am used to.

Hopefully I have not gotten anything wrong.

Here is also a link a post about ASA ARP behaviour

http://www.packetu.com/2011/11/07/the-asas-arp-behavior/

- Jouni

[Federico Coto Fajardo]

Jouni just to clarify, should the NAT be reversed:

global (LAN) 1 10.10.10.100

nat (DMZ) 1 192.168.10.0 255.255.255.0

Because LAN (security level = 100) and DMZ (security level = 50)?

In other words, the "normal" NAT will be from LAN to DMZ correct?

global (DMZ) ...

nat (LAN) ...

[Jouni Forss]

Hi,

Oh right the old format wouldnt probably accept that configurations. I mean when you are doing Dynamic PAT from lower to higher "security-level"

It would probably need to to use the "outside" parameter at the end of the "nat" command

global (LAN) 1 10.10.10.100

nat (DMZ) 1 192.168.10.0 255.255.255.0 outside

I am not saying the above Dynamic PAT configurations makes any sense. I would personally never even configure Dynamic PAT/NAT between local interfaces. Just was thinking as you mentioned there was a lot of Dynamic NAT/PAT configurations that I would use an example where the actual PAT address is from a directly connected network but NOT the interface IP address, which would mean that Proxy ARP would need to be active on the interface holding the PAT IP address.

- Jouni

[Federico Coto Fajardo]

Thank you Jouni,

The same will be true (following your example), if I also have a static NAT?

static (LAN,DMZ) 192.168.10.200 10.10.10.200 

If I want the LAN host 10.10.10.200 to be "seen" in the DMZ as 192.168.10.200 this will also mean that I also need Proxy ARP enabled on the DMZ interface?

I mean with the configuration:

global (LAN) 1 10.10.10.100

nat (DMZ) 1 192.168.10.0 255.255.255.0 outside

static (LAN,DMZ) 192.168.10.200 10.10.10.200 

This means I cannot disable Proxy ARP neither on LAN or DMZ is this correct?

Federico.

Then

[Jouni Forss · Accepted solution]

Hi,

Yes, this is my understanding atleast.

On the other hand if the situation was that both the Dynamic PAT and Static NAT used a mapped IP address that doesnt belong to the directly connected network of the mapped interface, neither interface would require Proxy ARP as the device behind either interface would be forwarding the traffic to their default gateway (ASA interface IP) and when the packet reached the interface of the ASA it would match the destination IP address to the configured Static NAT or and existing PAT translation (return traffic) and go through with no Proxy ARP involved in the whole process.

global (LAN) 1 10.1.1.100

nat (DMZ) 1 192.168.10.0 255.255.255.0 outside

static (LAN,DMZ) 192.168.1.200 10.10.10.200 

- Jouni

[Federico Coto Fajardo]

Excellent Jouni,

At least we have the same understanding at this point :-)

Thank you very much,

Federico.