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.