masscan "could not determine default interface" on tester box
Fixes masscan failing to determine the default interface on a tester box by naming the interface and router explicitly. Use when masscan exits with could not determine default interface before scanning an authorized range. Not for permission errors, which masscan reports separately.
TL;DR
Masscan builds its own network stack and needs to know which interface and gateway to use; on multi-homed tester boxes, VPN setups, and containers it cannot guess, so it quits before sending anything. Read the routing table, pass the interface and router IP explicitly for the authorized range, and the scan starts.
masscan "could not determine default interface" on tester boxUse this when
- masscan exits immediately with could not determine default interface on the tester machine.
- The box has several interfaces, a VPN, or runs masscan inside a container or VM.
Not for this skill when
- masscan starts scanning and then finds nothing. That is a routing or target question after startup, not this error.
- The message is about permission or raw sockets. Fix privileges for that separate error.
Steps
- List interfaces and routes on the tester box and identify which interface actually reaches the authorized range. Verify: Verify: you can name the interface and its gateway for the in-scope network.
- Run masscan with the interface named explicitly, for example with the --interface option set to that adapter, against one in-scope host first. Verify: Verify: masscan starts and reports on the single test host.
- If it still cannot build routes, also pass the router IP and, where needed, a source IP and MAC consistent with that interface. Verify: Verify: the startup banner shows the chosen interface, source address, and gateway.
- In a container or VM, switch to host networking or a bridged adapter for the scan, since NAT layers hide the real interface from masscan. Verify: Verify: inside the scan environment, the interface from step 1 is visible.
- Save the working invocation in the engagement runbook so every later masscan run on this box reuses it. Verify: Verify: a second operator can start a scan from the runbook without rediscovering the settings.
Variant phrasings
masscan --interface router-ip multi homed tester
The explicit-options phrasing.
masscan cannot find gateway vpn interface
The VPN phrasing.
masscan fails to start container no default route
The container phrasing.
Compatibility: Compatibility: masscan 1.3.x on Linux; interface names and route commands differ on macOS and Windows builds.
Why it happens
Unlike tools that borrow the operating system TCP stack, masscan crafts packets itself and therefore needs an explicit link layer identity: interface, source MAC and IP, and gateway. Auto-detection reads the default route, and when there are several defaults, a VPN tunnel, or a virtualised adapter, the guess fails and masscan refuses rather than scanning out of the wrong interface.
Edge cases / pitfalls
- Scanning out of the wrong interface can send traffic outside the intended path; always confirm the egress interface matches the engagement network plan.
- Explicit MAC settings that conflict with the real adapter can blackhole replies; copy values from the interface, do not invent them.
- High-rate scans still need the agreed rate cap for the authorized range, regardless of which interface is chosen.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_UAucBNC4NrBEkRneRr1E5A