One static IP across any internet line: how TunnelNet Business works
TunnelNet Business gives a whole site one real public IPv4 address. The router at the site connects to us, the address lives with us, and it stays the same when the main internet line fails and the router moves to a backup line. This paper explains how that works, how we tested it in our lab, what we measured, the bug we found on the way, and what it does not do.
The problem
Many connections cannot be reached from outside at all
Starlink, T-Mobile and Verizon 5G home internet, and many rural and cellular providers, share one public address among many customers. The industry name is CGNAT. Your router has an address, but not one the internet can reach.
So the port forward on your router never sees a visitor. Dynamic DNS only points a name at an address nobody can connect to. Camera apps, remote desktop, phone systems and anything else that needs people to reach the site from outside simply stop at your provider's equipment. Our guide Stuck behind CGNAT? What it means for a small business has a two-minute check that tells you whether your line is affected.
Even a normal line usually has a changing address
Lines that are not behind CGNAT usually still get a dynamic address. It can change after a power cut, a modem swap or a provider's maintenance. Every partner, monitoring company or service that only lets in known addresses then has to be told again.
Two lines means two addresses
The usual answer to an unreliable line is a second one: Starlink plus a cellular modem, or cable plus 5G. Most business routers can switch your outgoing traffic to the backup line on their own. But each line has its own address from its own provider. When the router switches lines, anyone trying to reach the site is still knocking on the first line's address, and nothing answers. A backup line keeps your staff browsing. It does not keep the site reachable.
How it works
The address lives with us, not with the line
Each site gets a dedicated public IPv4 address from our own network block. That address is not tied to Starlink, to your cable company or to any one line. It is announced on the internet by our network, and traffic for it arrives at our side first.
The router holds an encrypted tunnel to us
The router at the site keeps one encrypted tunnel open to TunnelNet. The tunnel is WireGuard, an open, widely used encryption standard. The router starts the connection, so it works through CGNAT and through any line that can reach the internet at all.
When someone connects to the site's address, we check whether that port is open and whether they are allowed to use it. If they are, we send the connection down the tunnel to the router, and the router hands it to the device you chose, such as a camera recorder on 192.168.88.10. The reply goes back the same way, through the tunnel, so the visitor sees it come from the site's address.
When the main line fails
- The router checks every second whether line 1 still reaches the internet.
- When line 1 stops answering, the router sends the tunnel out through line 2 instead and sends one packet down it straight away.
- Our side sees the tunnel arrive from a new place and follows the new path. Nothing needs to change on our side, and nothing needs to change in DNS, because the address never moved.
- When line 1 comes back, the router moves the tunnel back to it.
The site has one encryption key, not one per line. That keeps the setup simple: the same tunnel just takes a different road.
What a router needs
Two routers work today: MikroTik (RouterOS 7) and OPNsense. For each one we generate a setup file for your site and a five-step guide. The setup adds the tunnel, puts the site's address on it, adds one forward for each port you open, makes sure replies go back through the tunnel, and adds the line checks that move the tunnel to the backup line. UniFi, Peplink and GL.iNet are coming soon. We list a router only once we have tested it.
What we tested and how
The lab
We built a test site for each router in our lab:
- The router. For MikroTik, MikroTik's own virtual router running RouterOS 7.25.1. For OPNsense, OPNsense 26.7.
- Two internet lines. Each router had two separate internet ports, line 1 and line 2. Both lines went through a stand-in provider that translated addresses twice, the way a CGNAT line does. The router never had a public address of its own.
- A camera stand-in. A small web server behind the router on the site's private network, answering like a camera's web page.
- A typical customer's base setup first. Before adding anything of ours, each router was set up the way a normal two-line site would be: line 1 as the main line, line 2 as the backup.
- Our setup on top, exactly as a customer downloads it. The only edits were the line settings that the guide asks every customer to fill in, and the private key, which your browser fills in for you.
Each test site was connected to our real network through the same path a customer uses, on an internal test account, with one port open to one allowed address.
The method
- A rented server outside our network, in another part of the country, tried to load the camera stand-in at the site's public address every 200 milliseconds, with a 0.8 second time limit, and logged every answer with a timestamp.
- 20 seconds in, we cut line 1. The router's port stayed up, so it looked fine to the router. The stand-in provider simply stopped passing any traffic on that line. That is the harder case: a line that is plugged in and "up" but carries nothing, which is how many real outages look.
- 80 seconds in, we restored line 1.
- We measured the longest stretch with no answer after the cut, and again after the restore.
Before each run we checked that the tunnel was really on line 1. For some runs we also captured the tunnel's packets on both lines, to prove it really moved and moved back.
We also checked the allowlist from the other side. From the allowed address, the camera stand-in answered. From an address not on the list, nothing answered.
Results
Every number below was measured in our lab, with the setup above. These are lab results, not a promise. Your time depends on your router and your lines.
MikroTik (RouterOS 7)
| Run | Line 1 cut: no answer from outside for | Line 1 back: no answer for |
|---|---|---|
| 2 | 1.8 s | none seen |
| 3 | 2.6 s | none seen |
| 4 | 2.6 s | none seen |
| 5 (with packet capture) | 1.8 s | none seen |
Runs 2 to 5 use the setup we ship. In our lab, the site's address answered again 1.8 to 2.6 seconds after line 1 was cut, on the same address throughout. When line 1 came back, the switch back showed no missed answers at our 200 millisecond probe rate.
The capture in run 5 shows the tunnel really moving. The tunnel's packets stopped on line 1 at the cut and appeared on line 2 straight away. At the restore they moved back to line 1 and stopped on line 2.
OPNsense
| Run | Line 1 cut: no answer from outside for | Line 1 back: no answer for | Tunnel back on line 1 afterwards |
|---|---|---|---|
| 1 | 5.0 s | none seen | yes |
| 2 | 4.2 s | 1.0 s | yes |
| 3 | 5.0 s | none seen | yes |
| 4 | 5.8 s | 1.0 s | yes |
| 5 | 5.0 s | none seen | yes |
With the setup we ship, the address answered again in every one of 5 cuts, after 4.2 to 5.8 seconds, measured in our lab. Each time line 1 came back, the tunnel returned to line 1, which we checked by capture on both lines.
Most of those seconds are the line check itself. OPNsense decides a line is down after three missed checks in a six-second window, one check a second. Checking faster would risk switching lines on a short blip, so we left it there.
Our first OPNsense design used only the settings pages. In testing it was several times slower, once it did not recover until line 1 came back, and it stayed on the backup line afterwards. So the setup we ship adds one copy-paste command that moves the tunnel as soon as OPNsense switches lines. The table above is that shipped setup.
The bug we found in run 1
Our first MikroTik run was far slower than the ones above, so we left it out of the table and went looking for the reason.
The setup is meant to send one packet into the tunnel the moment it switches lines, so our side learns the new path at once. In run 1 that packet was never sent. The command used a setting that RouterOS's ping command does not have, so it failed quietly. Our side only followed the tunnel at its next regular check-in, several seconds later.
We fixed the command to send the packet through the tunnel directly, and added an automated test that fails if the old form ever comes back. Runs 2 to 5 are the fixed setup. We show run 1 because it is part of what happened, and because it shows why we test the file a customer actually downloads rather than a hand-tuned copy.
Honest limits
- One shared upstream, not two carriers. In our lab both lines left through the same internet connection. A real site has two different providers, so our side sees the tunnel arrive from a different provider's address. The tunnel handles that the same way, but it is not what we measured.
- Incoming only, for now. Today the site's address is for people and apps reaching the site, and for the replies. The site's own browsing, email and updates still use its own lines, and switch the way your router already switches them. A whole-site mode, where all of the site's outgoing traffic also leaves from its TunnelNet address, is coming soon on the same plan. It is not available yet.
- Which line is in use is not in the dashboard yet. The dashboard shows whether the site is connected. It does not yet show which line carries the tunnel, or a history of switches. That is listed as coming below.
- Your time depends on your router and your lines. A different model, a slow backup line or a line that fails slowly instead of all at once can all change the result. Connections that were open at the moment of the switch may need to reconnect.
- Two routers so far. MikroTik and OPNsense work today. The OPNsense numbers come from OPNsense 26.7 only.
- The OPNsense command lives outside OPNsense's own settings. Restoring a settings backup or reinstalling removes it, and you paste it again. We expect it to survive a firmware update, but we have not tested that yet.
We do not promise an uptime percentage. We publish our measured uptime, outages included.
Security model
The key is made in your browser
When you download a router setup file, your browser makes the site's private key and puts it into the file. Only the public half is sent to us. We never see the private key and we do not keep a copy. Each download makes a new key, and the file you downloaded before stops working.
Every port is closed until you open it
A new site answers nothing. You open a port for a device you choose, and only that port reaches only that device. Nothing on the router itself can be reached through the tunnel: the setup file adds rules on the router that drop anything you have not opened.
Only the people you name
Any open port can be limited to a list of addresses, such as your office or your monitoring company. We check that list on our side, before traffic ever reaches your line, so nobody else can even try the port. If you choose to open a port to anyone, the dashboard warns you first.
What we keep
We don't record what passes through your connection. We count bytes, for your data allowance, and nothing more.
What's next
These are not available yet. We list them so you know where this is going, and we will not charge for anything before it exists.
- Whole-site mode (coming): all of the site's outgoing traffic through its TunnelNet address, chosen per site in the dashboard.
- Down and up alerts (coming): a text and an email when a site stops answering, and when it is back.
- Which line is in use (coming): status for each line and a history of every switch.
- Installer view (coming): all your clients and their sites in one place.
- Open-camera warnings (coming): a warning when a camera or recorder admin page is open to everyone.
Try it
TunnelNet Business is $49 per site per month, including 1 TB of traffic a month. Each site gets one dedicated public IPv4 address, a main and a backup line on the same address, any port with source allowlists, the dashboard and router setup files, and setup help on your first site by email. Cancel any time from your dashboard.
Setting up a MikroTik router? See Setting up a MikroTik site in ten minutes. Read more on the TunnelNet Business page, or add your first site.
Questions, or a router we don't list yet? Email support@minakilabs.com. Support is by email only. TunnelNet is operated by MinakiLabs LLC.