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 4301321940
arp-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.1234
arp-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.1234
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
arp-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#
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.
:cool: