Skip to main content

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 show

Look 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 detail

Check 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 / FreeBSD

You should see an address in the 10.254.x.x/24 range. The exact subnet depends on your hub:

HubSubnet
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    # Frankfurt

If 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/ping

The 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.1

If 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 wg0

Blocked 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:

  1. Try from a different network (mobile hotspot, home broadband)
  2. Check with your network administrator about UDP filtering
  3. Contact a Torus administrator about alternative port options

Getting Help

If you’ve worked through all the steps above and still cannot connect:

  1. Note which step fails and the exact error output
  2. Include your hub region and WireGuard interface status (sudo wg show)
  3. Contact an administrator through the dashboard or community channels