ike-scan gets no response from a working IPsec gateway

The gateway serves phones and laptops every day, yet ike-scan reports no hosts responded. That output reads like proof that IPsec is missing from the device. Usually it means the device discarded every proposal in the probe and chose to answer nothing. Silence is a response, and it is the least informative one the tool can give you.

Work through three separate questions: did the packet arrive, did any proposal match, and did something else refuse the peer?

Step 1: read the proposal the tool sends

Main mode begins with an SA payload that lists the transforms the initiator will accept, and ike-scan fills that list from a compiled default. The default set is deliberately old: DES and 3DES for encryption, MD5 and SHA1 for hashing, groups 1 and 2 for the key exchange, pre-shared keys for authentication. No AES, no SHA-2, no group 14. A gateway configured for AES-256 with SHA-256 and modp2048 shares nothing with it.

Some implementations answer an unmatched probe with a NO-PROPOSAL-CHOSEN notify. Others simply drop it, which is common on appliances that treat unknown peers as noise. Either way the scan prints nothing, and that nothing is identical to what a filtered UDP 500 looks like from the outside, as the ike-scan project documentation makes clear about the default set.

Step 2: offer one modern proposal

Replace the default set with --trans. The attribute form takes IKE attribute numbers directly: 1 for encryption, 2 for hash, 3 for authentication, 4 for the group, and 14 for key length when the algorithm takes one. What comes out is a line you can read aloud in a change review.

The positional form carries the same values in order and avoids brackets, which matters once the command travels through a shell.

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

One proposal per packet is slow when you enumerate, so loop over the plausible values: encryption 5, 7/128, 7/192, 7/256; hash 1, 2, 5, 6, 7; groups 1, 2, 5, 14, 15, 19, 20, 21; authentication 1 for a pre-shared key and 3 for RSA signatures. Print each command before running it so the transcript shows what was offered and in which order.

Step 3: interpret a reply

A reply proves exactly two things: an IKE responder is reachable at that address, and one offered proposal was acceptable. It says nothing about the pre-shared key, the L2TP layer, or whether a user account exists. A successful scan is entirely compatible with every later stage failing.

On a gateway you operate, this is the genuinely useful part. The scan tells you which proposals the device still accepts, and a result limited to legacy transforms is a finding about device policy, not a reason to weaken the client.

Step 4: interpret silence

Silence is weaker evidence than it looks. Every proposal may have been rejected, UDP 500 and 4500 may be filtered, the source may be rate-limited after a burst, or the service may listen on a different address than the one you scanned. Compare the gateway's IKE log with a client that already connects using valid credentials before you conclude anything about the box.

Burst behaviour belongs in that list because enumeration generates many packets in a short window. A gateway that answers the first attempts and then goes quiet is describing its anti-DoS policy rather than its proposal set.

Step 5: record what you proved

Write the accepted combination next to the firmware version, then compare it with the transforms the clients you care about offer by default. The gap between those two lists is the configuration problem, and the scan only made it visible. If the only accepted proposals are ones you would not choose, the fix belongs in the gateway policy or in a client profile, never in the probe.

A probe that never answered has still answered something: it shows which proposals this device is willing to discuss, and which it would rather drop on the floor.