Cisco ASA./FTD上的代理arp开关引发的故障

场景如下：

内网服务器对外映射
映射是在出口防火墙FP2110 (Cisco Firepower 2110) 上配置的，公网用户访问 59.61.77.148的公网Ip失败。

拓扑如下：

先说结论：
ASA或FTD上未开启代理ARP
如何开启？
命令：

conf t
 arp permit-nonconnected 

为什么proxy arp会影响对外映射的业务？

cisco community :

https://community.cisco.com/t5/network-security/arp-permit-nonconnected/td-p/2226198

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.