Publish a server with no public address
To put a server behind these load balancers, they have to be able to reach it. That normally means a public address and a hole in a firewall. Arranging both is often the longest part of the job and sometimes it is not possible at all.
When this is the right answer
- A web server in an office, with no public address.
- A data center that will not give you public addresses for every machine, or charges for them.
- A backend you would rather was not reachable from the internet at all, even through a firewall rule.
- Somewhere you want to move a service between networks without changing anything on the load balancers.
If a backend already has an address the load balancers can reach, you do not need this. Add it to a pool in the ordinary way.
It is not a VPN, and the difference matters
The machine gets a route to these load balancers and to nothing else. It does not change where that machine's own traffic goes and it gives it no way out to the internet. A tunnel that did those things would be a much bigger decision than this one.
Step 1: turn the tunnel on
- Fleet, Tunnel.
- Click Turn the tunnel on.
- Choose an address range. The suggestion is
10.77.0.0/24, which is fine unless something on your network already uses it. - Leave the listening port at 51820 unless you have a reason to change it. Whatever you choose has to be reachable outbound from wherever your workloads are.
- Tick it on and save.
You choose the range rather than the system choosing it, because you are the only one who knows what is already in use on your network. A range that clashes with something else does not fail loudly. It quietly makes one of the two unreachable.
The range cannot be changed later
Changing it would strand every enrolled workload, so the page refuses once any are on it. Choose carefully now.
Step 2: install tunnel support
The tunnel needs a package on each load balancer, and it is not installed until you switch the tunnel on. Installing a network package on somebody's production load balancers because a page was open is not a decision this system makes on its own.
If any node is missing it, a panel appears saying which one, with a button to install it on all of them. Click it and wait. It installs on every load balancer, because a workload connects to all of them so that it survives one going away.
Step 3: add a workload
- Click Add a workload.
- Give it a name. This is only for you and only appears in this list.
- Add a note if it helps, such as what it runs or who owns it.
- Click Add it.
A command appears. It looks like this:
curl -sSL https://lb-01.example.com/lb/tunnel/enrol/7f3c1a9e2b8d4c6f | sudo bashTreat it like a password while it is alive
It works once and expires after two hours. Anybody who has it can put a machine on your tunnel. Only a hash of it is kept, so the exact command cannot be shown to you again, but you can always get a fresh one from the workload list.
What you are about to pipe into a shell
Worth knowing. The script is short and deliberately readable, and you can look at it first by leaving off the last part of the command.
curl -sSL https://lb-01.example.com/lb/tunnel/enrol/7f3c1a9e2b8d4c6f | less| It does | It does not |
|---|---|
| Install WireGuard if the machine lacks it | Change the machine's default route |
| Make a key pair, sending only the public half back | Send that machine's own traffic anywhere |
Write one interface called nfm0 | Open any inbound port |
| Add a route to the load balancers and nothing else | Give the machine internet access it did not have |
| Leave a helper command for checking and undoing it | Remove anything when you undo it later |
When it finishes, it waits for the tunnel to come up and tells you whether it did. An interface that exists and a tunnel that works are not the same thing, and the difference is usually a firewall that drops outbound UDP on the tunnel port. Better to find that out here than from a backend marked down later.
Step 4: put it behind a site
- Note the workload's tunnel address from the Tunnel page, for example
10.77.0.4. - Backend Pools. Open the pool you want it in, or make a new one.
- Add a server using the tunnel address and the port the service listens on.
- Apply config.
From here it behaves like any other backend. Health checks run over the tunnel like any other check, so the pool page shows it up or down in the usual way.
Use the port the service really listens on
A pool whose other members are on port 82 does not oblige a tunneled member to be on port 82. The tunnel address is a normal address and the port is whatever that machine uses.
When it does not work
| Symptom | What it usually is |
|---|---|
| Enrolled but the backend is down | The tunnel is up and the service is not. Check the service is listening, on the port you used in the pool. |
| Nothing happened at all | Run sudo nfm-tunnel status. Usually a container whose kernel has no WireGuard, or a firewall that drops outbound UDP on the tunnel port. |
| Works through one load balancer and not the other | The workload cannot reach one of them. Often an address family problem, such as a load balancer published on IPv6 only while the workload has IPv4 only. Use a name with both an A and an AAAA record. |
| The command expired | Click Show the command for a fresh one. The old one stops working immediately. |
Removing a workload later
Two halves, and only one of them happens in the GUI.
- Take the address out of any pool that uses it, and apply. Otherwise the pool points at something that has gone.
- Tunnel page, Remove next to the workload.
- Copy the command shown and run it on the machine.
- Click Remove it here.
It deliberately leaves the WireGuard package installed, because that machine may be using it for something else, and removing a package from somebody's server based on a copied line is not a decision to make lightly.