How the VPN works

Witina’s VPN puts a technician’s computer on a customer’s network, so they can use their own tools there: RDP, a file share, a printer’s setup page, a vendor’s management app. The technician runs the Witina VPN app, turns on the sites they need in the browser, and the app opens a WireGuard tunnel to a gateway at each one. Nothing is installed at the customer’s site beyond the gateway that’s already there.

The pieces

• The Witina VPN app, on the technician’s Windows, macOS, or Linux computer, holds the tunnels. See Connect with the Witina VPN app.
• A gateway at the site carries each tunnel into the network.
• The Witina cloud decides who may connect where, introduces the app and the gateway to each other, and keeps the record. VPN traffic doesn’t pass through it.

On the VPN pages, a site is a region: a session connects you to a region’s network. Any gateway in the region that can run the VPN can carry a session there, and Witina picks one for each session. See Regions.

The VPN runs on gateways installed from the Witina image (the Hyper-V command, the OVA, or the ISO) and on gateways run with Docker; see Run the VPN on a Docker gateway. Gateways on Kubernetes can’t run it yet.

How the tunnel is made

Neither end needs a port forwarded to it.

1. When a technician turns a site on, Witina picks one of the site’s gateways and tells it about the session over the gateway’s existing connection.
2. Each end asks two STUN servers which public address and port its traffic leaves from, and Witina passes the answers to the other end.
3. The gateway sends a few packets toward the technician’s addresses, which opens a path back through the site’s NAT. At the same time, the app sends WireGuard handshakes toward the gateway’s addresses. The first path that answers is the one the tunnel uses.

This takes about a second. Traffic then goes directly between the technician’s computer and the gateway, encrypted by WireGuard. On the customer’s network, connections come from the gateway’s own address, so devices see the gateway rather than the technician’s computer.

The gateway’s network has to allow outbound UDP; see Gateway network requirements.

When there’s no direct path

Some networks give each destination a different public port, as some phone hotspots and carrier networks do. When both ends are on networks like that, or no answer comes back within about 5 seconds, the tunnel can’t be made directly and needs Witina’s relay. The relay isn’t available yet. Until it is, the app shows an error saying the connection needs it.

When the technician’s network changes

The app follows a change of network, such as moving from office Wi-Fi to a phone hotspot, docking a laptop, or waking it from sleep. The sites stay on, and the tunnel finds its new path within a few seconds.

What a session reaches

A session reaches the site’s routes: the private IPv4 networks Witina has seen on the site’s devices in the last 30 days, and any networks an administrator adds. A session takes the routes as they are when it starts. The gateway lets the session’s traffic into those networks and drops anything else.

Names: split DNS

While a site is on, names in its DNS domains, such as customer.internal, are looked up at the site’s DNS servers, through the tunnel. So are reverse lookups for the site’s routes. Every other lookup uses the technician’s own DNS, as before.

Overlapping addresses: aliases

A customer’s network often uses the same range as the network the technician is on, such as 192.168.1.0/24, or the same range as another site that’s on at the same time. So each of a site’s routes also gets an alias in 100.96.0.0/12 for the session. An alias keeps the last two numbers of each address: when 192.168.1.0/24 is 100.96.1.0/24, 192.168.1.20 is 100.96.1.20.

• A route that doesn’t clash can be reached both ways: by its real addresses and by its alias.
• A route that clashes with the technician’s own network can be reached only by its alias. The app says so.
• Names in the site’s DNS domains resolve to the alias, so connecting by name works either way.
• A network larger than a /16 has no alias.
• A session keeps its aliases until it ends. The next session from the same computer to the same site gets the same aliases when they’re free.

Who can connect

• Nobody connects until a policy lets them. A policy names teams, the places they may connect to (every site, every site of a customer, or particular sites), and the longest a session may last, up to 8 hours. Policies add up: there are no deny rules, and when two policies let someone into a site, the longer session length applies. See Policies.
• Roles don’t let anyone connect. They decide who can see and change the VPN’s settings and policies, and other people’s sessions. See Permissions.
• Access is checked again as things change. Turning a policy off, deleting it, or taking someone off its team ends the sessions that no policy allows any more.
• The gateway holds each session’s end time itself, so a session ends on time even if the gateway loses its connection to Witina.

What’s recorded

• Every session: who, from which computer, through which gateway, when it started and ended and why, and the bytes each way.
• Every connection made through the tunnel, as a flow record: when, the address and port it went to, how much each way, and the gateway’s address and port as the site saw it. Your organization keeps them for 90 days unless you change it. With them, Who was it turns a line in a customer’s firewall log into the technician who made it. See Sessions and flow records.
• The activity log records turning the VPN on or off at a site, changes to policies and settings, people starting, extending, and ending sessions, and apps being connected and disconnected.

The traffic itself isn’t recorded.