topic Clarification on ASA in Network Security

Clarification on ASA

Federico Coto Fajardo — Tue, 12 Mar 2019 02:51:12 GMT

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:

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.
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.

Clarification on ASA

Jouni Forss — Fri, 11 Oct 2013 19:24:05 GMT

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

Clarification on ASA

Jouni Forss — Fri, 11 Oct 2013 19:37:51 GMT

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

Clarification on ASA

Federico Coto Fajardo — Fri, 11 Oct 2013 19:56:49 GMT

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.

Clarification on ASA

Federico Coto Fajardo — Fri, 11 Oct 2013 20:03:20 GMT

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.

Clarification on ASA

Jouni Forss — Fri, 11 Oct 2013 20:19:35 GMT

Hi,

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

- Jouni

Clarification on ASA

Federico Coto Fajardo — Fri, 11 Oct 2013 20:27:26 GMT

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.

Re: Clarification on ASA

Jouni Forss — Fri, 11 Oct 2013 20:46:17 GMT

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

Clarification on ASA

Federico Coto Fajardo — Fri, 11 Oct 2013 20:56:34 GMT

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,

Re: Clarification on ASA

Jouni Forss — Fri, 11 Oct 2013 21:22:11 GMT

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

Re: Clarification on ASA

Federico Coto Fajardo — Fri, 11 Oct 2013 21:31:29 GMT

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) ...

Clarification on ASA

Jouni Forss — Fri, 11 Oct 2013 21:36:42 GMT

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

Clarification on ASA

Federico Coto Fajardo — Fri, 11 Oct 2013 21:42:29 GMT

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

Re: Clarification on ASA

Jouni Forss — Fri, 11 Oct 2013 21:55:09 GMT

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

Clarification on ASA

Federico Coto Fajardo — Fri, 11 Oct 2013 21:57:37 GMT

Excellent Jouni,

At least we have the same understanding at this point 🙂

Thank you very much,

Federico.

Re: Clarification on ASA

Jouni Forss — Fri, 11 Oct 2013 22:01:46 GMT

Hi,

No problem,

Let us know how the situation evolves. Would be interesting to know what is causing the problems. If this is caused by something intentional action rather than normal network behaviour (considering the environment)

- Jouni

Clarification on ASA

Federico Coto Fajardo — Fri, 11 Oct 2013 22:15:30 GMT

Will do.

Thanks,

Clarification on ASA

Federico Coto Fajardo — Tue, 15 Oct 2013 16:21:03 GMT

One more thing:

With this configuration:

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

We said that the ASA requires Proxy ARP in both LAN & DMZ in order to be able to respond with it's own MAC address to requests being send to the NATed IP.

Question:

What about if the next L3 device on both interfaces have a static route pointing to the ASA?

For example:

ip route 192.168.1.200 255.255.255.255 ASA-DMZ-IP

ip route 10.1.1.100 255.255.255.0 ASA-LAN-IP

Shouldn't this take care that all packets WILL be sent to the ASA (thus removing the need for the ASA to do Proxy ARP)?

Federico.

Re: Clarification on ASA

Jouni Forss — Tue, 15 Oct 2013 16:42:43 GMT

Hi,

Well if we consider the example setup when the LAN network is 10.10.10.0/24 and the DMZ network is 192.168.10.0/24 and we are NATing DMZ IPs to the LAN network addresses and LAN network addresses to DMZ network addresses...

Then it still doesnt remove the fact that the connected L3 device will see this network as directly connected (as we are NATing to the connected network address space from behind the other interface of the ASA). And directly connected network naturally overrides any static route for the same network and therefore the device will ARP for the MAC address of the destination address.

Whether there is some way around this behaviour I am not sure

- Jouni

Re: Clarification on ASA

Federico Coto Fajardo — Tue, 15 Oct 2013 17:38:06 GMT

Jouni,

Correct me if I'm wrong but if you have a more specific route it will indeed overide the directly connected.

Say you have directly connected 10.0.0.0/24

If you enter a static route to 10.0.0.5/32, then most specific route wins and therefore packets are going to be sent to the ASA which eliminates the need for Proxy ARP on that interface?

Federico.