Nmap Shows Different Results Over VPN? Pin the Target
A hostname can resolve to another address once the tunnel is up. Hold the numeric target fixed before you read anything into changed port states.
Two port scans of the same website can disagree because the name resolved to a different address between runs, not because the tunnel changed what the target exposes. A hostname is a lookup instruction, and Nmap follows it at scan time. When the resolver answers with a different record, the second scan measured a different machine.
Pin the numeric address and the comparison becomes meaningful again. Everything else in the report, from timing to middleboxes, stays a separate variable that needs its own control.
Two experiments that look identical in a report
Compare a name against itself and you have changed at least two things at once: the path your packets take and the destination the resolver returned. A difference in the output cannot be assigned to either one. That ambiguity is the usual reason a before-and-after scan turns into an argument nobody can settle.
Compare an address against itself and the destination is fixed by construction. Whatever still differs belongs to the path, the source address, the filtering in between, or the machine's own state. You have removed one variable, which is not the same as removing all of them.
Write down which of those two experiments you actually ran before drawing any conclusion from a port table. The distinction sounds academic until a report says the VPN blocked a port that was never open on the address you hit the second time.
| Comparison | What stays fixed | What a difference can mean |
|---|---|---|
| Name against name | The string you typed | Resolver answer, answer order or split-horizon policy changed |
| Address against address | The numeric destination | Source path, filtering or service placement changed |
Resolve first, then scan the address you recorded
Split resolution from probing so the two facts land in different places. Ask the system what it resolved, save that answer, then hand Nmap the literal address. Repeat the same two commands with the tunnel down and up.
getent hosts scan.example.net dig +short scan.example.net A nmap -Pn -sV -p 443,8443 192.0.2.40
The -Pn flag matters here, because a host that ignores discovery probes would otherwise be reported as down and the empty result misread as a closed port. Use -sV only against destinations the operator has approved; version probing is louder than a bare connect and belongs inside the written scope.
Nmap's target specification reference is explicit that a hostname is resolved to an address before scanning, and that when several addresses come back the tool scans the first unless you ask for all of them. Nothing in that behaviour is VPN-specific. Split-horizon DNS, a different resolver, or a load balancer answering in a new order produces the same effect without any tunnel involved.
Keep the resolved value next to the scan output, with the address family, the flag set and a timestamp. A reverse lookup that returns a company name is another observation, not proof of which backend answered.
What a changed port state can and cannot tell you
Once the destination is pinned, a port that flips from open to filtered usually points at the path. Think of an upstream ACL, a stateful firewall, or a provider that treats tunnel egress differently from residential egress. Narrow it by testing a second approved address in the same subnet when the scope allows, because swapping the hostname would reintroduce the resolver question. One variable per run is the whole method.
A port that stays open while the service banner changes is a different story. That pattern fits a front end distributing connections across backends, and no amount of scanning from your side will name the tenant behind it.
What the scan never tells you is intent. A filtered port is a policy outcome, not evidence that someone singled out your tunnel, and an open port is not evidence that the application behind it will serve you. Correlate with logs on the component you operate before writing either story.
Recording results so the comparison survives review
A useful record holds the requested name, the resolved address and its family, the exact flags, the source address in use, and the authorization that covered the destination. Add the time, because DNS answers rotate and a report without timestamps invites the same argument twice. Add the scanner version as well, since default probe behaviour drifts between releases. If two runs used different methods, treat them as different experiments and say so in the heading rather than the footnote.
Label the finding for what it is: different destinations, different source paths, or a difference still unexplained. That vocabulary keeps a scan report honest, and it stops a resolver answer from being republished as a VPN interception event. The next step is usually one more run with the address pinned, not a broader scan.