cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
28130
Views
94
Helpful
9
Replies

arp permit-nonconnected

Tormod Macleod
Level 1
Level 1

Hello,

I'm in the process of upgrading our ASA software from 8.2 to 9.1 and I've noticed the 'no arp permit-nonconnected' command in our config. I had a look at the command reference http://www.cisco.com/en/US/docs/security/asa/asa90/command/reference/a3.html#wp1824414 and just wondered whether someone could give me some more background on this command at situations in which you might use it.

I should add that I've set up our test environment to use 9.1 without any issues despite the fact that we have NATd devices from non connected networks in use the NAT works just fine. The address doesn't show up in the arp cache but this is the case on our ASA running 8.2

Forgive my ignorance but I can't see why you would want the ASA to cache the mac address / ip address relationship. Shouldn't the ASA just route the traffic to the internal address and let the default gateway of the internal device worry about the ARP cache.

Like I say, please forgive my ignorance. I'm just looking to understand more about this command and it's possible applications before I enable it in our live environment.

Cheers,

Tormod

1 Accepted Solution

Accepted Solutions

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

The most common reason for someone to configure "arp permit-nonconnected" on the new software on their ASA is when the ISP has allocated 2 public subnets to the customer and configured both of those networks on their gateway interface. For example the network that is link network between the ASA and the ISP gateway and an additional subnet as an "secondary" network on the gateway interface.

In this case you would run into problems the first time if you upgraded to software level 8.4(3) which changed the ARP behaviour with ASA firewalls. In this software there was no simple command to change this behaviour and the mentioned command only became available in the next updates to the software.

The reason you might not be facing any problems depends on how your network is set up.

For example lets take the situation that you have 2 public subnets from the ISP. Other subnet is configured directly on the "outside" interface of the ASA and the other one is just used as Static NAT IP addresses or similiar. Now if your ISP has configured a route for this secondary subnet and routed it towards the current "outside" IP address of the ASA then we will NOT run into any problems with ARP and nonconnected subnets as the ISP will never ARP for the MAC address of any of those IP addresses from the secondary IP addresses as they are not a part of a directly connected network for the ISP (Problem would arise if the gateway device had this secondary subnet as directly connected). Instead the ISP forwards the traffic to the next hop which is ASA and there will be no problems.

Now if we consider a situation next where the ISP has configure the 2 subnets directly on its gateway interface. One as the link network between the ISP gateway and your ASA and the other as an additional "secondary" subnet for NAT use. Also if we consider that you have the default setting for your software level and have "no arp permit-nonconnected" you will run into problems with connectivity with the secondary subnet.

What will happen is that a user on the Internet will try to connect to some of your servers using the secondary public IP address space. The traffic will reach the ISP gateway which will see the public IP address as a part of a directly connected network. Now the ISP will send an ARP request that tells the ASA that the ARP requests senders IP address is from the secondary subnet and this secondary subnet is not an directly connected network to any ASA interface so the ASA wont populate its ARP table with the ISP gateway interfaces secondary IP/MAC where the ARP request came from or was sourced from. In other words ISP will never get an ARP reply from the ASA. And naturally when the ISP isnt able to determine the MAC address of the secondary subnets destination IP address the connections will fail.

Hope this helped and clarified things

Please do remember to mark the reply as the correct answer if it answered your question.

Ask more if needed.

- Jouni

View solution in original post

9 Replies 9

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

The most common reason for someone to configure "arp permit-nonconnected" on the new software on their ASA is when the ISP has allocated 2 public subnets to the customer and configured both of those networks on their gateway interface. For example the network that is link network between the ASA and the ISP gateway and an additional subnet as an "secondary" network on the gateway interface.

In this case you would run into problems the first time if you upgraded to software level 8.4(3) which changed the ARP behaviour with ASA firewalls. In this software there was no simple command to change this behaviour and the mentioned command only became available in the next updates to the software.

The reason you might not be facing any problems depends on how your network is set up.

For example lets take the situation that you have 2 public subnets from the ISP. Other subnet is configured directly on the "outside" interface of the ASA and the other one is just used as Static NAT IP addresses or similiar. Now if your ISP has configured a route for this secondary subnet and routed it towards the current "outside" IP address of the ASA then we will NOT run into any problems with ARP and nonconnected subnets as the ISP will never ARP for the MAC address of any of those IP addresses from the secondary IP addresses as they are not a part of a directly connected network for the ISP (Problem would arise if the gateway device had this secondary subnet as directly connected). Instead the ISP forwards the traffic to the next hop which is ASA and there will be no problems.

Now if we consider a situation next where the ISP has configure the 2 subnets directly on its gateway interface. One as the link network between the ISP gateway and your ASA and the other as an additional "secondary" subnet for NAT use. Also if we consider that you have the default setting for your software level and have "no arp permit-nonconnected" you will run into problems with connectivity with the secondary subnet.

What will happen is that a user on the Internet will try to connect to some of your servers using the secondary public IP address space. The traffic will reach the ISP gateway which will see the public IP address as a part of a directly connected network. Now the ISP will send an ARP request that tells the ASA that the ARP requests senders IP address is from the secondary subnet and this secondary subnet is not an directly connected network to any ASA interface so the ASA wont populate its ARP table with the ISP gateway interfaces secondary IP/MAC where the ARP request came from or was sourced from. In other words ISP will never get an ARP reply from the ASA. And naturally when the ISP isnt able to determine the MAC address of the secondary subnets destination IP address the connections will fail.

Hope this helped and clarified things

Please do remember to mark the reply as the correct answer if it answered your question.

Ask more if needed.

- Jouni

Thanks very much for taking the time to explain this to me. I'm very grateful

Hello Jouni,

I am experiencing similar problem. Multiple public subnets assigned by ISP via one cable. One is directly connected, second two are not directly connected nor assigned as secondary ip adress on inteface. Both subnets are configured on separate inteface instead and these interfaces serves as default gateway for some of your equipment with public ip address. Sometimes it happens our router with public IP behind ASA stops communicating to internet. This occurs rarely, but it happens. When I reboot the router, connectivity to internet will always fail after router boot up. Only way how to make it work again is to issue "clear arp" command on ASA. 

I configured "arp permit-nonconnected" and will see after router reboot.

Anyway thank you for deep explanation, If this command solves our problem, will rate your post.

Cheers. 

It sounds like Proxy-arp with a different name?

I recall in the past there was a sysopt command to enable or disable it.

I will test it on my ASA running 9.x code and see if its there, or it was deprecated

Software Version 9.6(1) still has sysopt noproxyarp command 

I know this is an old thread, but I encountered the same issue with FTD 2130, the command was not available in the GUI. Firepower 2130 has the command disabled by default.

Leveraged Flexconnect and executed the command "arp permit-nonconnected"

Hi, I cannot put in the command into flex config, my FMC running on version 6.2.3.3, anyidea?

 

1.PNG

Hi, Its not supported on 6.2.3.x there is a work around to enable arp permit-nonconnected.

 

https://community.cisco.com/t5/security-documents/arp-permit-nonconnected-in-cisco-ftd-6-2-3-x-workaround/ta-p/3738651

 

HTH 

-Abheesh

thank you . excellent post
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: