Tunnel status and reloading
A tunnel is an encrypted link between our network and another one — your office, a partner, or another provider — so the two sides can reach each other privately.
Tunnels are set up for you and assigned to your account; you don’t create them yourself. The Tunnels page shows the ones that are yours, with their status and logs, and lets you reload IPsec tunnels when they drop.
Reading the status
Section titled “Reading the status”| Status | Meaning |
|---|---|
| Up | Negotiated and carrying traffic. |
| Down | Configured but not currently established. |
| Unknown | We can’t determine the state right now — usually the edge device didn’t answer. |
Unknown is not the same as down. It says the status check failed, not that your tunnel did. If traffic is flowing, the tunnel is fine regardless of what the panel says. Reload if traffic is genuinely not passing, not because the label reads Unknown.
Reload an IPsec tunnel
Section titled “Reload an IPsec tunnel”If an IPsec tunnel is down and you expect it up, Reload renegotiates it: the tunnel disconnects and immediately reconnects.
- Go to Tunnels.
- Find the tunnel and choose Reload.
This affects only your tunnel. It’s the right first response to a tunnel that dropped after a connectivity blip on either side, or one stuck after the far end changed something.
A reload interrupts traffic for a few seconds while the tunnel re-establishes, so don’t do it mid transfer if you can help it.
Why WireGuard tunnels have no reload
Section titled “Why WireGuard tunnels have no reload”WireGuard is connectionless by design. There’s no session to tear down and rebuild — it simply sends encrypted packets when there’s traffic and stays quiet when there isn’t. A WireGuard tunnel showing no activity often isn’t broken; it has nothing to carry.
So there’s nothing for a reload button to do, and we deliberately don’t offer a fake one. If a WireGuard tunnel isn’t passing traffic, the cause is configuration or routing on one of the two sides — open a ticket from Support and we’ll look at it with you.
If a reload doesn’t fix it
Section titled “If a reload doesn’t fix it”A tunnel needs both ends to agree. When one side changes, it stays down until they match again.
Check on your side first:
- Is the far end reachable at all? If its public address changed, the tunnel can’t find it.
- Did anything change recently — a firewall upgrade, an ISP router swap, a new public IP?
- Do the phase settings still match? Encryption, authentication, DH group and lifetimes have to agree on both ends. A change on either side brings the tunnel down until the other follows.
- Are the subnets still right? If a network behind either end was renumbered, the tunnel may come up while traffic goes nowhere.
The tunnel’s logs in the panel are the fastest way to tell these apart. Repeated negotiation attempts point at mismatched settings; silence points at the far end being unreachable.
Traffic isn’t passing but the tunnel is Up
Section titled “Traffic isn’t passing but the tunnel is Up”An established tunnel only carries the networks it was configured for.
- Confirm the address you’re reaching falls inside the subnets the tunnel covers.
- Check the route on your server — traffic for the far side has to be sent through the tunnel, not out the default gateway.
- Check the firewall on both ends. A tunnel delivers traffic; it doesn’t decide whether the host at the other end accepts it.