We don't need our ISP's static IPs anymore
Our own office runs on a UniFi Dream Machine SE. On November 9 we gave it a public IPv4 address through TunnelNet instead of from our internet provider. Here is what that means, what we measured on the first day, and what broke, and what we're still testing.
Why a business wants an address of its own
Plenty of things at an office need to be reached from outside: a camera recorder, a file server, remote desktop, a test web page, a supplier who only lets in addresses on their list. All of them need a public address that stays the same.
Internet providers usually sell that as an extra: a static IP plan, often only on business service, and not on every connection. Starlink and 5G home internet often don't offer it at all. And the address belongs to that one line. If the line changes, so does the address.
What we did instead
The office gateway keeps a private, encrypted connection to TunnelNet. The public address lives on our network, not on the internet line. When someone outside connects to that address, the connection comes down the tunnel to the gateway, and the gateway passes it to the one machine and port we opened.
Only incoming connections use the address. Everyday browsing at the office stays on our normal internet line, exactly as before.
One plain fact: we're still under contract with Comcast, our internet provider, for a block of static IP addresses. We'll cancel it when the contract ends, because TunnelNet now does that job.
What we measured on day one
We put a small test page on a server at the office and checked it from a server of ours in Miami, once a second, for 77 minutes.
| What | Result |
|---|---|
| Checks from Miami, once a second | 4,605 |
| Checks that failed | 7 (0.15%). Three of those were us restarting the test server. |
| Time for the office to answer, seen from Miami | about 135 to 140 ms |
To be complete: earlier that morning, while we were still setting things up, we saw one gap of about 28 seconds where the test page didn't answer. The tunnel itself stayed connected the whole time. We haven't found the cause yet, and we'll write it up when we do.
These are numbers from one office, one line and one day. They are not a promise about anyone else's connection.
Bugs we found, so far
- The setup file. UniFi refused our first setup file until we added a line to it by hand. That's the kind of step a customer should never see, which is why UniFi sites now install with one command instead of a file.
- Visitors' addresses. At first our test server saw every visitor as coming from TunnelNet itself, not from their real address. That breaks logs and blocklists. Our UniFi agent now passes the real address through, and our office sees it.
- A history that cried wolf. When we tried our new Diagnose assistant on our own site, it found that the dashboard's history showed short disconnects that never happened. The fix is written and waiting to go out.
- The 28-second gap above: still open.
From hand work to one command
Getting our own gateway working took hand work that a customer shouldn't have to do: we added a line to the setup file before UniFi would accept it, and we set up the rules for incoming connections by hand.
So we built a small agent that runs on the gateway and does that part for you, installed with one command from the portal. You open or close a port in the TunnelNet portal, and the agent applies it. In our lab, on a test gateway set up like a UniFi one:
- a port opened, closed or moved in the portal worked from outside 7 to 19 seconds later;
- after a reboot, the site answered again 44 to 58 seconds after the gateway booted;
- when the gateway rewrote its own firewall rules, as UniFi gateways do on their own when settings change, the agent put the TunnelNet rules back. Visitors outside saw a gap of 1.2 to 2.3 seconds.
Those are lab numbers, not numbers from our office gateway.
What we're still testing on our own gateway
- Reboots and a UniFi firmware update on the real gateway, with the address answering again afterwards.
- A switch to a backup internet line. Our office has one line today, so this waits for a second one.
We'll replace the lab numbers above with our office's own as each test runs. MikroTik and OPNsense routers work too; the Business page has the details.
Running UniFi yourself? The UniFi page has the setup. Questions: support@minakilabs.com.