WASViking Sentinel Tunnel

Scan the applications that never touch the internet. Install the Sentinel agent inside your network, register it with a one-time token, and let it open an outbound mTLS tunnel that you can rotate or revoke at any time.

Your most sensitive applications are usually the ones a cloud scanner cannot see: the staging environment behind the VPN, the internal API that only the office network reaches, the admin panel on a private address. Testing them normally forces a bad choice: open a hole in the firewall for a vendor, or leave them untested.

The WASViking^® Sentinel removes that choice. It is a small agent you install on one Linux host inside your network. The agent dials out to the WASViking cloud over mutual TLS and keeps a tunnel open; scan traffic for your internal targets flows through that tunnel. Nothing connects in. Your firewall keeps every inbound port closed, and the scans reach the private addresses of your Dev and STG infrastructure as if the scanner were sitting next to them.

Why your security team will approve this

This is the part to bring to the security and compliance review before installing anything:

• Outbound only. The agent opens one outbound HTTPS connection on port 443. No inbound ports, no NAT rules, no VPN accounts for a third party, nothing for an external attacker to find.
• Mutual TLS with a per-agent identity. During registration the agent receives its own client certificates, bound to your organization. Both sides authenticate; a connection without a valid client certificate for your org is refused.
• You hold the kill switch. Every agent can have its token rotated or be revoked from the portal, and a revoked agent is cut off immediately. Access by WASViking to your internal network exists only while you keep an agent registered and running.
• One-time bootstrap. The registration token is shown once and is valid for a single registration. After that, the certificate is the identity; the token is useless to anyone who finds it later.
• Scoped reach. The agent only scans the internal targets you register in the portal, and you can restrict its network reach further with your own firewall rules around the host it runs on.

The full transport and hardening detail lives in Sentinel architecture; it is written to be handed to a security reviewer.

Where this helps in the day to day

• Dev and STG before release. The same scan engine that covers your public site runs against pre-production addresses, so issues are caught before they ship.
• Internal-only applications. Intranet apps, internal APIs, and admin panels get the same findings workflow, risk scoring, and compliance mapping as everything else.
• Segmented networks. Install one agent per segment or data center; the portal routes each scan through the right agent.
• Evidence for the auditor. Internal applications show up in your posture with scan history, which answers the recurring audit question about coverage beyond the public perimeter.

Pre-requisites

Step 1: Open the Sentinel Agents page

In the portal, go to Sentinel → Sentinel Agents.

The status pills across the top (Total, Active, Pending, Offline, Revoked) summarize your fleet, and the table lists each agent with its hostname, address, status, and last heartbeat. The Actions column is where the control lives: Details, Rotate Token, and Revoke.

Sentinel → Sentinel Agents.

Step 2: Register the agent and copy the token

Click Add Sentinel Agent and give it a display name. This is a human label shown in the portal, not the machine hostname, and it must be unique in your organization. Name it after the site and segment it will serve, for example Florida - DMZ Internal STG 01, so that a year from now the table still reads like a map of your network.

A human-friendly label, unique in your organization. You can rename it later.

Click Create. The portal shows the RAW bootstrap token once. Copy it and store it safely; it is what you will use on the host in the next step. The token authorizes a single registration, so if you lose it before registering, use Rotate Token on the agent row to mint a fresh one.

The bootstrap token is displayed once. Copy it before closing.

If you are rolling out several segments, Create another repeats the flow without leaving the dialog. One agent per segment or data center is the pattern that scales.

Step 3: Install and register on the host

Click Get Agent to open the install instructions for your platform. For Ubuntu/Debian the flow is three commands long.

Download the .deb package and, if your change process requires it, check the SHA256 and signature with the Verify download link. Then install and enable the service:

sudo dpkg -i wasviking-sentinel_<version>_amd64.deb
sudo systemctl enable --now wasviking-sentinel

Register the agent with the token from Step 2. Registration runs once per agent: it securely downloads the client certificates that become the agent's identity and writes the configuration to /opt/wasviking-sentinel/configs/config.yaml.

cd /opt/wasviking-sentinel
./wasviking-sentinel register --token <YOUR_TOKEN_FROM_PORTAL>

sudo systemctl start wasviking-sentinel
sudo systemctl status wasviking-sentinel

Get Agent: download, install, register, start.

Step 4: Confirm the tunnel is up

Back on Sentinel → Sentinel Agents, the agent flips from Pending to Active and the Last Seen column starts updating with its heartbeat. That is your confirmation that the outbound tunnel is established.

If the agent stays Pending for more than a few minutes, the cause is almost always one of these:

• Outbound connectivity on port 443 is blocked for that host.
• A corporate proxy or TLS interception appliance is breaking the mutual TLS handshake. The tunnel needs to pass through untouched.
• The system clock is off; check NTP.

The step-by-step diagnosis lives in the troubleshooting section of Installing the Sentinel agent.

Step 5: Run the first internal scan

Register an internal target the same way you registered your first public one, but point it at the private address (for example https://stg-app.internal.local or http://10.20.30.40:8080).

Then start the scan at Scans → New Scan (/portal/scans/new). This is the step that actually routes the scan through the tunnel: in Preferences → Scan Method, set Execution Path to Sentinel Tunnel (Internal) and pick your agent in the Sentinel Agent dropdown, for example Florida - DMZ Internal STG 01 (Active).

Do not leave Execution Path on Direct (External) for an internal target. Direct is for addresses that are public on the internet; the cloud scanner cannot reach a private address, so an internal scan dispatched as Direct has nothing to test. Sentinel Tunnel (Internal) plus the right agent is what carries the scan safely to the internal address.

Preferences → Scan Method: Execution Path and the agent created in Step 2.

Click Scan now. The scan is dispatched through the tunnel, runs against the internal address, and the findings land in the same Findings workflow as everything else, with the target clearly marked as internal.

The target fields, authentication options, and per-agent routing are documented in Internal scanning.

Operating the fleet

• Rotate Token issues a new bootstrap for an agent, which is the move when a token leaked before registration or when you rebuild a host and need to re-register.
• Revoke cuts the agent off immediately. Registered certificates stop being accepted, scans stop routing through it, and the row stays in the table for the audit trail.
• One agent per segment. Agents are cheap to run; give each network segment or data center its own, name them consistently, and target routing picks the right one.
• The same installed binary also runs sbom and secrets against your repositories, so the host you just set up can feed the supply chain modules too.

Where next

• Point your first internal target at the agent: Internal scanning.
• Hand the transport design to your security team: Sentinel architecture.
• Put the same binary in your pipeline: wasviking-sentinel in CI/CD.
• Schedule recurring internal scans: Scan Schedules.