Nessus over VPN: scanner placement before the first scan

A VPN icon beside the browser says nothing about the process that sends the scan packets. If the console and the scanner run on different hosts, the browser's tunnel is one path and the scan's source is another. Start with the execution point, then work outward to the route, the authorization and the credentials. That distinction is the first item on the checklist for a reason.

This is a pre-launch checklist, not a scanning tutorial. Each step produces a fact you can put in the engagement record before any packet leaves the scanner.

Check one: locate the process that sends the probes

Draw the three roles explicitly: the browser on laptop A, the scan console on host B and the private target C. If B also runs the scanning engine, the browser only needs a path to B. If a separate scanner appliance does the work, that appliance needs the path to C.

Browser on laptop A -> console on host B
Scanner process on B (or another appliance) -> private target C

A browser connected to the VPN can reach the console while the scanner behind it still has no route to C. The reverse is also possible: the scanner is inside the private network and the console is remote. Find out which arrangement you actually run before changing any network control. Name the appliance in the scan configuration before you blame the network.

If the scanner runs on A, the browser host and the scanner share a context, but only while that process keeps the same namespace and routing table. A container or a service account may not inherit what the interactive browser sees. The console is a management surface, not the scan engine.

Check two: prove the scanner's route and DNS

Run the route check on the scanner host, not on the laptop. Ask the kernel which interface and gateway it would use for the target address, then repeat for the target's hostname. A route that exists for the IP and a name that resolves to a different address are two different failures.

Confirm the source address that will appear at the target. A VPN client can assign an address different from the one the target's firewall expects, and a NAT device can rewrite it again. The target owner needs the observed source, not the address printed in the VPN profile.

Check the return path as well. A scanner that reaches the target but receives no replies has a routing or firewall problem on the way back, and that looks identical to a target that is down.

Check three: get the scope and viewpoint authorized

Have the target owner name the systems, services, environment, source and time window in writing. Decide which viewpoint the assessment represents: an outside VPN user, an admitted internal client or a specific scanner segment.

A private route is not permission to test adjacent networks. Keep the target list narrow, list excluded systems and agree on stop conditions and a contact who can halt the run. The scanner will happily probe whatever it can reach, which is exactly why the scope has to be explicit.

Record the approved source in the same document. If the scanner's observed source differs from the approved one, the run does not represent the agreed viewpoint even when the target list is correct.

Check four: match credentials to the assessment depth

A reachability check and an authenticated assessment are different tests. A port response proves that something answered; it does not prove that credentialed checks ran or that the application authorized the account.

Use dedicated credentials only when the agreed scope requires authenticated checks. Confirm the account's permissions and lockout policy, and decide how findings will be stored and shared before the scan produces them.

If credentials fail, do not silently fall back to an unauthenticated run and label the report as the planned assessment. The result is a different test with a different meaning, and the difference belongs in the report.

Check five: save the plan, then launch deliberately

In the Nessus scan workflow, choosing a template, configuring settings and saving or launching the scan are separate steps. Use that separation to review the target list, source and schedule before any traffic starts.

Before you authorize the launch, check what source the VPN permits, which traffic it carries and how it recovers from a dropped tunnel. Do not widen firewall access merely because a preliminary connection failed; find the layer that refused it and fix that layer.

After the run, record the scanner host, its observed source, the target list and any checks that could not complete. A report produced from a different source or without the intended credentials does not represent the original plan, and saying so is part of the deliverable.

Retire the engagement access and handle retained results through the agreed process. The checklist is finished only when the evidence matches the path you approved, not when the scan simply returned results.