VPNs explained from scratch: tunnels, ports, SSH and RDP

Starting point: how your machines talk

Let's begin with the simplest picture. On the Internet, every machine has an IP address — think of it as a postal address. When your computer sends data, it slices it into small packets, writes the recipient's address on each one, and hands them to the network. Every router along the way acts like a sorting office: it reads the address and forwards the packet. Your data therefore passes through many hands that do not belong to you.

Web encryption (the HTTPS padlock) protects the content of one conversation with one website. It is essential, but it does not solve the problem we care about here: your own machines — the PC at home, the office server, the workshop camera, the laptop on 4G — each live behind a home router or a mobile network, cannot see one another, and have no safe way to reach each other remotely. The naive way to connect them is to expose them on the public Internet. That is exactly what must be avoided, and the rest of this page explains why and how.

The VPN: a private tunnel through the Internet

VPN stands for Virtual Private Network. The most accurate analogy is the tunnel: imagine a private, armored corridor built through public space, directly linking your buildings together. From the outside, all you can see is an opaque wall — there is no way to know what travels inside. Inside, your machines behave as if they were in the same building, plugged into the same local network.

Technically, here is what happens: every member machine receives a private address, valid only inside your network. When one machine writes to another, the packet is encrypted on the spot, carried across the Internet like any other traffic (the sorting offices only see an opaque envelope), then decrypted only on arrival, by the recipient. Nobody else — not the routers along the way, not the relays, not the service operator — holds the key.

A concrete example: your PC is in Toulouse, your server in Paris, your phone on 4G at a work site. Once all three are enrolled in the same VIGIL-MESH network, each sees the other two by their private address or their name. From the work site, typing the server's name is enough — as if it were in the next room:

# Reach the server by name (MagicDNS), wherever it is
ping serveur-paris

# Open a remote terminal on it — port 22 never exposed to the Internet
ssh admin@serveur-paris

One last piece of vocabulary: classic corporate VPNs route everything through a central server (a “hub-and-spoke” topology). VIGIL-MESH is a mesh VPN: machines talk directly, peer to peer, which shortens paths and removes the central point of failure. The detailed comparison lives in Next-generation mesh VPN.

Creating your network: identities and a member list

How does the tunnel know who is allowed in? Think of a very strict club. At the door, a member register is the source of truth: that is the controller's role. Every machine that joins the network receives a forgery-proof identity card: a cryptographic key pair, generated on the machine itself — the private key never leaves it. The controller then distributes the signed network map to everyone: who is a member, under which address, with which rights.

1. 1
   Create the workspaceThis is your club: a space where your networks, machines and rules will live. It takes a few clicks in the console.
2. 2
   Enroll each machineOn each machine, the client generates its key pair then introduces itself to the controller (enrollment key, invitation, or manual approval). Once accepted, the machine receives its stable private address.
3. 3
   Machines see each other by nameThanks to MagicDNS, every member is reachable by a readable name (serveur-paris, camera-atelier) rather than an address to memorize. The network is ready.

The detailed walkthrough, with screenshots, is in Account and workspace then Enroll your first machine.

Ports: the numbered doors of every machine

An IP address designates a machine, but a machine often provides several services at once. Here is the analogy to remember: a machine is a building, its IP address is the building's address, and its ports are 65,535 numbered doors. Behind some doors, someone is waiting: a service. Behind door 22, an SSH server listens; behind 3389, an RDP remote desktop; behind 443, a web server; behind 554, an IP camera's video stream. Knocking on a door means opening a connection to that port.

“Opening a port” on your home router means carving a door of your building straight onto the street. And the Internet is a very busy street: bots roam it around the clock and knock on every door of every address, methodically. A 3389 (RDP) door open to the Internet receives its first connection attempts within minutes, then continuous password guessing. Most intrusions are not targeted attacks: they are doors left facing the street.

Blocking and allowing: ACLs, your concierge

Moving every door inside the tunnel is huge progress, but one question remains: inside the private network, should everyone be able to open every door? No. The intern has no business connecting to the production database, and the camera has no reason to talk to the payroll server. That is the role of access control lists (ACLs): a concierge posted at every door, checking the badge of whoever knocks before opening.

The fundamental principle is called default deny: whatever is not explicitly allowed is forbidden. You never write the list of what you block — it would be endless. You write the short list of what you allow, and everything else is refused outright. Rules are read top to bottom, and the first match decides:

Read this table as sentences: “admins can do everything on production”; “the supervision workstation can see the cameras, and only their video stream”; “the contractor reaches a single machine, on a single port”. A stolen or compromised machine can only knock on the doors its identity card allows — and you can revoke that card at any time from the console.

The full mechanics — ordered rules, signed generations, offline verification — are detailed in Policies and ACLs.

The SSH terminal: a remote keyboard inside the tunnel

The terminal is the oldest and most efficient interface there is: you talk to the machine in text. You type a command, it answers. SSH (Secure Shell) extends this idea across a distance: it is a keyboard plugged into another machine, through an encrypted link. Every key you press travels encrypted to the remote machine; every character it prints comes back encrypted to your screen. Anyone watching the line would only see noise.

Concretely, the remote machine runs an SSH server listening behind door 22. Your SSH client connects to it, both sides verify their keys (the machine proves it really is itself; you prove you really are you), then the session begins. In a VIGIL-MESH network, this connection travels through the tunnel: door 22 only exists on the private network side, never on the street side.

# The MagicDNS name is enough — no public IP, no port opened on the router
ssh admin@serveur-atelier

# Once connected, you are “inside” the remote machine:
admin@serveur-atelier:~$ systemctl status capteurs
admin@serveur-atelier:~$ tail -f /var/log/production.log

Why is this so valuable? Because a text terminal weighs almost nothing: a few bytes per keystroke. Even over a mediocre 4G link from a work site, administering a server over SSH stays smooth. It is the tool of choice for anything that is a server, a robot, an industrial gateway, or a headless machine.

SSH and RDP from a plain browser tab

SSH carries text. RDP (Remote Desktop Protocol) carries the whole screen: you see the remote machine's desktop, and your mouse and keyboard act on it as if you were sitting there. It is the natural tool for a Windows workstation, a graphical application, or helping a user hands-on. The trade-off: images stream continuously, which needs more bandwidth than a terminal — and it is precisely the service that must never be exposed to the Internet (door 3389 is the most knocked-on of all).

Now for the remarkable part. Ordinarily you would install a VPN client, then an SSH or RDP client. VIGIL-MESH enables something else: a browser tab can become a true member of the network. The node's core is compiled to WebAssembly and runs in the page; the connection to the mesh uses WebTransport (QUIC/HTTP3); the private key is generated in the page and never leaves it. The tab then gets its own socket surface on the private network — it can knock on a mesh machine's door 22 or 3389 exactly like a native client.

1. 1
   The page becomes a network memberThe WASM core authenticates with its key, receives the signed network map, and establishes its end-to-end encrypted session. The relay only sees opaque bytes pass through.
2. 2
   The tab opens a TCP connection inside the tunnelFor a terminal, the page connects to port 22 of the target machine across the mesh; for a desktop, to port 3389. No gateway decrypts in the middle: the SSH or RDP session is negotiated between the page and the target machine.
3. 3
   The interface renders in the pageThe terminal's text is rendered in the tab; for RDP, the remote screen is drawn in the page and your keystrokes travel back along the same encrypted path.

Measure the difference with classic “web bastions”: those gateways terminate the SSH or RDP session on their own server, then re-stream the display to you — so the bastion operator sees your session in the clear. Here, decryption only exists at the two ends: in your tab and on the target machine. The infrastructure transports; it does not read.

The takeaway: why do it all this way

Let's replay the whole lesson in one picture. Without a private network: doors carved onto the street, bots knocking day and night, services one weak password away from compromise. With a well-kept private network: no door on the street at all, an armored tunnel between your machines, a concierge at every door, and your administration tools — terminal and desktop alike — reachable from anywhere, even from a browser tab.

This is the reversal to remember: security no longer rests on a pile of exceptions (“that port, opened for that need, temporarily”) but on a healthy default state — everything closed, everything encrypted, and only the explicit is opened, inside a network that belongs to you alone.

Beginner's frequently asked questions