Nmap raw scan fails over a VPN but -sT connect works?

A page loads through the tunnel while a port scan reports the host as down, and the first instinct is that the VPN is blocking something. It usually is not blocking anything new. The two tests ask the operating system for different capabilities, and only one of them needs raw packet access. Work out which capability failed before you touch the tunnel.

Separate the capability from the tunnel

An ordinary application asks the kernel to open a TCP connection, and the kernel performs the handshake without special privilege. A raw scan builds packets itself, which needs a raw socket or a capture driver depending on the platform. Those are permission and driver questions, and they exist whether or not a VPN is connected.

The distinction explains the common asymmetry. curl succeeds because the socket path works, while the SYN scan fails because the process cannot open a raw socket on the tunnel interface. It also explains the reverse case, where a raw scan reports filtered because the path drops the probe while the application path stays fine.

Neither result describes the remote service. Both describe one path under one method, so keep the method attached to the conclusion.

Run the connect check on one approved host

Pick the single host your task covers, then use the mode that needs no raw access. The example target here is 198.51.100.24, documentation space reserved for this kind of illustration.

One line, one host, one port, no discovery stage:

nmap -sT -Pn -p 443 --unprivileged 198.51.100.24

-sT selects a full TCP connection, so it exercises the same kernel path an application uses and needs no capture driver. -Pn skips host discovery; nmap still performs link-layer resolution for targets on the local segment, so the flag is not a promise of zero preliminary traffic. --unprivileged tells nmap to assume it has no raw or sniffing rights, which changes the method and grants nothing.

Read each flag as one change, not a repair

Treat every option as a statement about method. None of -sT, -Pn or --unprivileged adds a route, opens a remote firewall or validates a certificate. A connect scan also completes a real handshake that the service logs, so an approved check and an unapproved sweep look alike from the server except for scope and rate. Stacking options until the output changes is how a method problem gets recorded as a network finding.

When output says closed, something answered with a reset, and that is a different finding from silence. When output says filtered, a device dropped the probe or its reply, and the VPN may be incidental. Write the exact wording down, because a discovery-stage verdict and a probe-level failure point at different layers.

If a privileged mode is genuinely required, the platform owner decides whether the privilege, driver and interface arrangement are supported. Elevating the same invocation does not change its method.

Stop at the transport result, then test the service

A completed handshake answers one question about one address, port, source and moment. It does not prove the backend is healthy, because a load balancer or forward proxy can accept the connection while the application behind it is down.

Follow it with the service's own client so TLS identity and application behaviour are observed as separate facts:

openssl s_client -connect 198.51.100.24:443 -servername staging.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.net/health

One more habit keeps the result useful. Note the exact command, the source address it used and the time, because a transport result without that context cannot be reproduced or compared.

If the certificate names a host you did not expect, transport worked and routing was never the problem; the fault sits in virtual hosting or DNS. If the handshake fails, record the local error string instead of generalising about the tunnel. Keep the scope note beside the result, because the next person needs to know which method produced it.