MultiOBXHow it works
What MultiOBX is built from
What this runs on and why it was built this way. Only what is in the code.
The base
The WireGuard protocol
The tunnel runs on WireGuard. Its cipher suite is fixed — ChaCha20-Poly1305 for traffic, Curve25519 for the key exchange — and there are no settings you could weaken by accident. The protocol is small, and its handshake has been formally verified.
The handshake fits into a single exchange of packets. So the connection comes up in a fraction of a second and survives a change of network: switch from Wi-Fi to mobile data and the tunnel carries on from where it was.
A service written in Rust
The service holds the tunnel and the firewall rules, and it is written in Rust. Not for fashion: it parses packets from strangers and runs with administrator rights, and in a program like that a memory bug is not a crash — it is somebody else's code inside your system. Most vulnerabilities in network software come from exactly those bugs, and Rust does not let you write them.
The app window lives separately and without administrator rights. It talks to the service over a Windows named pipe rather than a port on localhost, which a page open in your browser could have reached.
The gate goes up before the tunnel
Firewall rules are in place before a network adapter even exists.
Everything described in this section works with the firewall on. It is off by default, and deliberately so: until you know the program, a mistake of ours should not leave you without a network. Turn it on in the app: Settings, Protection.
With the firewall on, a dropped link, an unreachable server or a tunnel restart do not open the network — only the "Disconnect" button does. With it off, a drop sends traffic out directly, and the app says so with a red mark.
There is also a lock mode: with it on, the internet does not work without the tunnel at all, even after you disconnect by hand. Useful on a laptop that wakes up in a café or a hotel.
Layers of rules
- 1Programs
- Browser, mail, games. None of them knows what sits below, and none of them needs configuring.
- 2DNS layer
- Name queries are handled apart from everything else. Only the resolver inside the tunnel and 127.0.0.1 are let out — even if you allowed the local network. There is a test for this.
- 3Tunnel
- Everything that is not DNS goes inside WireGuard.
- 4WFP rules
- In place before a network adapter exists. Only the Disconnect button takes them down — not a fault, not a dropped tunnel, not a restart.
The rule that permits the connection to our server is bound to the service's executable. No other program can send a packet to the server's address outside the tunnel.
All the rules live in the Windows Filtering Platform. Any program that can read WFP can see them, and they do not depend on whether the app window is open.
When the network throttles traffic
Office, hotel and mobile networks often restrict or slow UDP: the internet works, the tunnel does not come up. So there is more than one way to connect, and the app tries them in turn.
- Plain UDP
- WireGuard as it is meant to run, and the fastest. Works at home and on almost every mobile network.
- Over TCP, port 443
- The same tunnel inside a TCP connection on port 443. That port is open nearly everywhere, because ordinary websites use it.
- Through two servers
- Traffic enters one server and leaves through another. The first sees your address but not where you are going; the second, the other way round. Available when there is more than one server.
- Through a network of anonymous relays
- The connection passes three relays, and none of them knows both the sender and the destination. Slower than the rest, but no server of ours is in the path. Nothing separate to install.
Which method got through is shown under "Diagnostics". We cannot guarantee a connection on every network.
Where the app gets server addresses
The app has to get the server list from somewhere. If the source disappears, you cannot connect even when the servers themselves are fine. This is the weak spot of any service like ours.
So the list is signed (Ed25519), and the public key that checks the signature is compiled into the app. That key is not on the server. A substituted list is thrown away. The list itself can be fetched by several independent routes: the main address, the spares, encrypted DNS queries to public resolvers. One working route is enough.
App updates are signed the same way. The private signing key is not kept on the servers: breaking into a server does not let anyone hand you someone else's program as an update.
What sits on the server
- The key
- 24 characters from a 31-character alphabet — no 0, O, 1, I or L, so nothing gets confused when copying by hand. The last character is a check digit: a typo is caught before anything is sent. The server holds an HMAC-SHA256 of the key; the key itself is written down nowhere.
- Devices
- A WireGuard public key, an address inside the tunnel, a name from a word list. The computer's real name is never asked for.
- The term
- The date your paid time ends. Nothing else.
- Logs
- The servers keep no connection logs: who, when, where to. There is nothing to keep.
- Key rotation
- Once every 30 days the key can be replaced from your account. Devices, addresses and paid days stay; the old key stops working immediately.
How to check
The list of installed rules is readable with Windows itself; the state of the service is shown by "Diagnostics" in the app. The commands, and what to look for in them, are on the Protection page.
If any point above turns out to be uncheckable, that is our failing. Tell us.
A two-minute check
Connect. Pull the cable or switch off Wi-Fi for a couple of seconds, then put it back. The internet returns only together with the tunnel — not before.