MultiOBXProtection
How the protection works
What is closed, what makes it hold, and what MultiOBX cannot do.
The main rule
With the firewall on, until you press "Disconnect", packets leave the computer in only two ways: inside the tunnel or to the address of our server.
The firewall is a setting, and it is off by default. That is deliberate: until you know the program, a mistake of ours should not leave you without a network. Turn it on in the app: Settings, Protection, "Firewall". While it is off, a dropped tunnel means traffic goes out directly, and the app says so with a red mark on the main screen.
With the firewall on, this is the order in which the service acts. First the rules "close everything except the server address" are set. Then the network adapter is created. Then the service waits for the handshake. Then it configures DNS. Only after that does it allow traffic through the adapter. Between the first and the last step nothing leaves the machine.
If the tunnel drops, the internet goes away until it reconnects. That is by design. The alternative, letting traffic go direct on failure, would mean that at the moment of failure you are unprotected and unaware of it.
States
The column describes the service with the firewall on. While it is off, traffic outside the tunnel is not closed in any state.
| State | Traffic outside the tunnel (firewall on) |
|---|---|
| Disconnected | allowed (or closed if "lock" is on) |
| Connecting | closed |
| Protected | closed, all traffic goes into the tunnel |
| Disconnecting | closed |
| Error | closed |
From any closed state there is one way to an open one: the "Disconnect" button. A failure, a lost server or a tunnel restart do not open the network.
DNS
The "Local network" permission opens access to the home router. A DNS query to it leaves the machine legitimately, the router forwards it to the ISP, and the ISP ends up with the list of sites you visited. That is why all traffic to port 53 is handled in a separate layer of rules where only the tunnel resolver and the local address 127.0.0.1 are allowed.
Keys
The WireGuard key pair is generated on the device. Only the public half goes to the server. The sign-in key is 24 characters, about 114 bits. The server stores an HMAC of it, not the key itself. Without the secret file the database is useless, and the key cannot be recovered from it.
What MultiOBX cannot do
- Hyper-V and WSL
- Hyper-V virtual machines have their own network stack, and Windows rules do not extend to it. Traffic from WSL may bypass the tunnel.
- The first seconds after boot
- Until the service has started, there are no rules. Persistent rules that apply from system boot are not implemented yet.
- A crash of the service
- If the service process crashes, Windows removes its rules and the network opens. This is a deliberate trade-off. Otherwise a computer would be left without network after a crash with no way to fix it.
- Android
- Even with the system setting that forbids connections without a tunnel, Android lets connectivity checks, network time and traffic to hotspot clients bypass it. This applies to every app.
- iOS
- The "all traffic" mode brings the behaviour close to the desktop, but system exceptions exist there too. With it on, AirDrop and some Apple services stop working.
- Anonymity
- MultiOBX hides from your ISP where you go, and from the site your address. It does not make you anonymous: signing in to a personal account through the tunnel identifies you more precisely than any IP address.
How to check
The "Diagnostics" section in the app shows the current state: whether the service has the rights to set rules, how many rules are in place and which ones, which DNS is in use, and when the last handshake happened. From the command line, multiobx doctor gives the same.
The list of rules, using Windows itself:
netsh wfp show filters file=filters.xml
Our rules are labelled with the provider "MultiOBX VPN". The file opens in any text editor.