I’ve been implementing a few Cisco ASA’s recently, and I blogged about this strange behavior; well I came across another one yesterday.
Take a look at this debug arp….
CiscoASA# debug arp debug arp enabled at level 1 CiscoASA# CiscoASA# arp-set: added arp outside 192.168.1.122 001e.7000.1234 and updating NPs at 4301321940 arp-set: added arp inside 192.168.1.61 001a.7100.1234 and updating NPs at 4301321940arp-in: request at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.73 001e.7a51.1234 arp-in: rqst for me from 192.168.1.125 for 192.168.1.73, on outside arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660 arp-in: generating reply from 192.168.1.73 001e.7a51.1234 to 192.168.1.125 001a.3000.1234 arp-in: request at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.69 001e.7a51.1234arp-in: request at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.120 001e.7a51.1234 arp-in: rqst for me from 192.168.1.125 for 192.168.1.120, on outside arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660 arp-in: generating reply from 192.168.1.120 001e.7a51.1234 to 192.168.1.125 001a.3000.1234arp-in: request at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.123 001e.7a51.1234 arp-in: rqst for me from 192.168.1.125 for 192.168.1.123, on outside arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660 arp-in: generating reply from 192.168.1.123 001e.7a51.1234 to 192.168.1.125 001a.3000.1234 arp-in: response at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.125 ffff.ffff.ffff arp-in: updating gratuitous ARP 192.168.1.125 - 001a.3000.1234 arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660 CiscoASA#arp-in: rqst for me from 192.168.1.125 for 192.168.1.69, on outside arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660 arp-in: generating reply from 192.168.1.69 001e.7a51.1234 to 192.168.1.125 001a.3000.1234
The firewall is replying to arp requests even though both the source & destination of the traffic are on the same (outside) interface, now I haven’t manged to work out why the firewall was doing this, but I did find a fix on the cisco forums.
sysopt noproxyarp outside
Names, IPs & MAC’s have been changed to protect the innocent.
Thanks… I performed a hairpin U-turn on my ASA, and forgot “sysopt noproxyarp outside”. Thus resulting in my network to stop working correctly.
Here is my config.
same-security-traffic permit intra-interface
global (inside) 1 interface
global (outside) 1 interface
static (inside,inside) netmask 255.255.255.128 norandomseq nailed
static (inside,inside) netmask 255.255.255.0 norandomseq nailed
route inside 255.255.255.0
sysopt noproxyarp inside