Connection Issues
Step-by-Step Diagnostics
If you cannot reach the Torus or the echo service, work through these checks in order. Each step builds on the previous one.
1. Is WireGuard Running?
Check that your WireGuard interface is up and has a valid handshake.
On Linux / macOS
sudo wg showLook for:
- interface — should show your private key (first few characters) and listening port
- peer — should show the hub’s public key
- latest handshake — should be less than 2–3 minutes ago
- transfer — should show non-zero rx/tx bytes
If latest handshake is missing or says never, the tunnel has not established. Check:
- Your internet connection is working
- The hub endpoint is reachable:
ping 18.169.231.26(London hub) - UDP port 13231 is not blocked by your firewall or ISP
On a MikroTik Router
/interface wireguard print
/interface wireguard peers print detailCheck that the peer shows a current-endpoint and recent last-handshake.
2. Do You Have a Tunnel IP?
Verify your WireGuard interface has the correct IP address assigned:
ip addr show wg0 # Linux
ifconfig wg0 # macOS / FreeBSDYou should see an address in the 10.254.x.x/24 range. The exact subnet depends on your hub:
| Hub | Subnet |
|---|---|
| London (eu-west-2) | 10.254.100.0/24 |
| Ohio (us-east-2) | 10.254.17.0/24 |
| Frankfurt (eu-central-1) | 10.254.20.0/24 |
3. Can You Ping the Hub Gateway?
Each hub has a gateway at the .1 address of its subnet:
ping 10.254.100.1 # London
ping 10.254.17.1 # Ohio
ping 10.254.20.1 # FrankfurtIf this fails but WireGuard shows a valid handshake, check your routing table. On some systems (notably FreeBSD), you need to manually add routes for the Torus subnets through the WireGuard interface.
4. Can You Reach the Echo Service?
ping 10.254.100.102
curl http://10.254.100.102/pingThe echo service runs on the London hub subnet. If you are connected to a different hub (Ohio, Frankfurt), cross-hub routing must be working for you to reach it. If your hub gateway responds but the echo service does not, it may be a cross-hub routing issue — contact an administrator.
5. DNS Resolution
If your VPN config includes a DNS setting, test it:
nslookup nekotopia.io 10.254.100.1If DNS is not resolving, verify the DNS server address in your WireGuard config matches your hub’s gateway.
Common Issues
Branch Router Users (MikroTik)
If you are accessing the Torus through a MikroTik branch router on your LAN, your LAN devices need source NAT (masquerade) to reach Torus addresses.
Without masquerade, your packets arrive at the echo service with a private LAN address (e.g. 192.168.1.x) that cannot be routed back. The fix is a masquerade rule on your MikroTik:
/ip firewall nat add chain=srcnat \
src-address=192.168.0.0/16 \
out-interface=wg-torus \
action=masquerade \
comment="Torus NAT for LAN clients"Replace wg-torus with your WireGuard interface name and 192.168.0.0/16 with your actual LAN subnet.
Latency Shows 0ms
If the echo service web page shows 0ms latency, try a hard refresh (Ctrl+Shift+R or Cmd+Shift+R). Your browser may be serving a cached version of the page.
Connection Drops After Sleep / Resume
WireGuard is stateless and recovers automatically, but your operating system may not re-establish the tunnel after sleep. Try:
sudo wg-quick down wg0 && sudo wg-quick up wg0Blocked by ISP or Firewall
WireGuard uses UDP port 13231 by default on the Torus. Some corporate networks and ISPs block non-standard UDP ports. If you suspect this:
- Try from a different network (mobile hotspot, home broadband)
- Check with your network administrator about UDP filtering
- Contact a Torus administrator about alternative port options
Getting Help
If you’ve worked through all the steps above and still cannot connect:
- Note which step fails and the exact error output
- Include your hub region and WireGuard interface status (
sudo wg show) - Contact an administrator through the dashboard or community channels