06-17-2013 01:46 AM - edited 03-11-2019 06:58 PM
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
Solved! Go to Solution.
06-17-2013 02:39 AM
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
06-17-2013 02:39 AM
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
06-17-2013 08:17 AM
Thanks very much for taking the time to explain this to me. I'm very grateful
10-18-2016 05:01 AM
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.
03-09-2017 05:44 AM
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
04-12-2017 06:12 AM
Software Version 9.6(1) still has sysopt noproxyarp command
03-03-2018 08:39 AM - edited 03-03-2018 08:40 AM
10-29-2018 11:28 PM
Hi, I cannot put in the command into flex config, my FMC running on version 6.2.3.3, anyidea?
11-02-2018 07:20 AM - edited 11-04-2018 12:07 PM
Hi, Its not supported on 6.2.3.x there is a work around to enable arp permit-nonconnected.
HTH
-Abheesh
12-18-2019 08:56 PM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide