On an ASA I help manage, the logs were full of messages like “Deny IP due to Land Attack from 1.2.3.4 to 1.2.3.4”. A Land attack is defined as when a packet is received that has the same source and destination IP addresses. Some definitions also say that the source and destination ports will match, but that was not true in my case.
Reproducing the issue
To reproduce the issue, I first got my public IP address, which is 1.2.3.4
Next, I set up the ASA to capture all packets it drops
Then I set up a loop to attempt a connect to my public IP address on a strange port (8955) so that I can search for it in the packet capture on the ASA later.
The logs confirm that I reproduced the issue
Looking for the dropped packets, I would expect the ASA to say the reason was a Land Attack since that’s what the logs say. Nope, it just says the reason is sp-security-failed.
The packet capture shows the source interface before any NAT happened. Let’s check packet tracer to see if the ASA is NATing the session
It is. Phase 4 of the packet trace shows a translation from 172.16.230.24 / 33885 to 1.2.3.4 / 33885
The fix
Put a NONAT (NAT exemption) rule in place
What this says is “if the source ip address is 172.16.230.24 and the destination ip address is in the range 1.2.3.4 through 1.2.3.90,” then ignore this NAT rule:
I tested by again creating lots of connections to 1.2.3.4 from the linux machine and now I don’t see Land Attack messages in the ASA system log. Another packet trace confirms that the NAT exclusion is working.