No SYN-ACK at all
The connection attempt left and nothing came back: no acceptance, no refusal. Silence is the least informative answer there is, which is what makes it the hardest to chase.
What it looks like
One SYN, then the same SYN again a second later, then again after two, then after four. The retries are the client's stack being patient. The report grades it Failed and says “The knock went unanswered”.
Why it is harder than a refusal
A reset tells you the packet arrived. Silence does not distinguish between a packet that never left your network, one that arrived and was dropped, and one that was answered by a reply that never came home. All three look identical from one end, and that is the point of the technique — firewalls drop rather than reject precisely so that scanning tells an attacker nothing.
What to do, in this order
- Capture at the far end at the same time. This settles it in one step. If the SYN arrives there, the problem is the return path. If it does not, the problem is outbound.
- Check the outbound policy first. It is the half you control, and the half most often responsible.
- Then routing.
ip route get <address>on the client, and the same at the far end for the reply. An asymmetric route is a common cause of one-way silence. - Then the security group, ACL or cloud firewall. These drop by default and log nothing.
One thing to rule out first
If your capture was taken with a filter, check the filter before anything else. A capture of
host X and port Y can genuinely miss a reply that arrived from a different address,
and an hour spent on a firewall that was never involved is an expensive way to learn that.