Choose the Right Observation Point for a Phone VPN Scan
A phone's VPN listener, a service on the phone and a routed LAN host are three surfaces. Walk these five steps and stop where the scope stops.
An authorised assessment of a phone-hosted VPN fails quietly when the scanner sits on the wrong side of the tunnel. You get results, they look plausible, and they answer a question nobody asked. Work through the five checks below in order. Each one has a stop condition, and stopping early is cheaper than re-testing from scratch after the report is written.
Step 1: name the surface you intend to reach
Three surfaces are routinely confused because one device connects them. They exercise different code and different policy, so write down which one is in scope before anything is started.
| Assessment target | What the path exercises |
|---|---|
| Public VPN listener on the handset | Reachability before login, plus the exposed VPN daemon |
| A service on the handset, by its tunnel address | Access after admission to something hosted locally |
| A LAN host behind the handset gateway | Forwarding, the return path and downstream access policy |
If the approved scope does not say which of the three, stop and ask. Rooting the phone does not answer this question, and it changes the thing under test rather than the observation point.
Record the targets, the permitted source addresses, the timing window and the intensity limit at the same time. The tunnel carries you to that scope; it does not license probing everything it can route.
Step 2: pick the source that can see that surface
A scanner sitting inside the VPN cannot reproduce an unauthenticated internet observer. It already holds routes, credentials and permissions that the outside observer lacks, so its results describe the post-admission view even when the target surface is the same. The reverse mistake is just as common. A public scan of the VPN port tells you almost nothing about a private service behind the login, and reporting it as if it did overstates the exposure in one direction and understates it in the other.
Stop if the source you can obtain does not match the surface. An assessment run from a peer inside the tunnel should not be presented as a pre-authentication result, and a test that requires an approved external source should not be quietly moved inside to avoid the paperwork.
Step 3: confirm the route and the reply path through the phone
When the handset forwards into another subnet, the scanner needs a permitted route and the target needs a return path that works. Confirm both instead of assuming that a ping reply means the path is complete.
ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8Source NAT changes what the downstream service sees. If the phone translates the scanner's address, the access rules and logs at the target apply to the translated address, so a service that appears to accept you may be accepting the phone rather than the scanner.
Watch for an overlap with the scanner's own network as well. If the phone routes 192.168.1.0/24 and the scanner sits on a LAN numbered the same way, probes hit local devices and the report describes them as the target. Check the route the scanner itself would use before sending a single packet.
Scan the real target address and keep the hostname the application needs for TLS identity and virtual hosting. Reaching a gateway proves the gateway answers; it does not test the service behind it.
Step 4: treat discovery as a probe with assumptions
Host discovery is where assessment results go wrong most often. Local Ethernet discovery does not cross a routed VPN, so the probes that work on a flat LAN simply do not arrive. Blocked discovery probes then make a reachable, authorised service look absent.
Decide deliberately whether to skip discovery and scan the known addresses directly, then say so in the report. A port that answers is not proof that VPN authentication succeeded, and a filtered reply is not proof that nothing listens. Rate is part of the same problem. A phone that throttles or drops under a fast scan produces filtered states that belong to the phone rather than to the service, so reduce concurrency and rescan before recording a port as closed.
The stop condition here is interpretation, not technique: if you cannot state what a state means for this path, the result belongs in an appendix rather than in the findings.
Step 5: hold the window, then close it
A phone is a poor server because it is designed to sleep. Battery optimisation, doze and Wi-Fi power management can suspend the app mid-assessment, and a tunnel reconnect can change the address the target uses. A run that spans one of those events has an invalid result window.
Hold the gateway role to the smallest scope the approved task allows, watch the tunnel while the run is live, and log the start and end of each window you report. When the assessment ends, remove the temporary access through its owner, keep the source and path record, and protect the output like any other test artefact.
If you need a repeatable observation point rather than a one-off success, that is the deliverable to argue for. The host discovery reference explains which probes assume a local segment, which is the detail that turns a blank result into a defensible statement.