Manual

The VPN connects but nothing passes

The tunnel is up, one counter climbs, and you get nowhere. That is nearly always routing.

Your phone or laptop says the VPN is connected. The light is green, the client is not complaining. But you cannot reach the NAS, you cannot ping the router, and names are not found.

This is a different problem from a tunnel that never comes up. If there is no connection at all, go to WireGuard never completes a handshake. Here the connection exists, and what goes wrong is what may pass through it and where it should go.

The quick checks, in this order

  1. Is traffic moving both ways? For WireGuard: /interface wireguard peers print. A good answer: rx and tx both climbing. Only rx means you arrive but the reply does not find its way back. For L2TP or SSTP: /ppp active print. For IKEv2: /ip ipsec active-peers print and /ip ipsec policy print, where the policy should read established.
  2. Does the tunnel have an address? /ip address print. A good answer: an address on the WireGuard interface, 10.10.10.1/24 for instance. Without one there is nothing to route from.
  3. Can you reach the router inside the tunnel? Ping the router's tunnel address from the client. If that works and the LAN does not, it is a matter of routes or of the firewall on the device inside. If it does not work, read the next step.
  4. Is the input rule stopping you? /ip firewall filter print stats while you ping. A good answer: the counter on drop all not coming from LAN stays still. If it climbs, the tunnel does not count as LAN and you are not allowed to reach the router itself, not even for DNS.
  5. Is there a route back? /ip route print. A good answer: for a peer with networks behind it there is a route to that network via the tunnel interface.
  6. Is anything arriving? /tool torch interface=wg-rw shows what goes through the tunnel. Nothing there, while the client says it is connected, means the client is sending its traffic somewhere else.

The usual causes

  • The client is not sending traffic through the tunnel. In a WireGuard client configuration, AllowedIPs decides what goes through. If it only holds the tunnel network, your office network is out of view. The tool writes 0.0.0.0/0, ::/0 for a full tunnel, and otherwise the tunnel network plus your LAN.
  • The tunnel does not count as LAN. The closing input rule only accepts traffic coming from the LAN list. If the WireGuard interface is not in it, you cannot manage the router or use it as a DNS server over the VPN.
  • Overlapping networks. If home is 192.168.88.0/24 and the office is too, your laptop sends the traffic to its own network and it never enters the tunnel. This is the most underestimated cause.
  • The firewall on the device inside. Windows and a NAS usually trust their own subnet only. The tunnel address is a different subnet, so it is refused.
  • An isolated VLAN on the far side. Isolation drops new traffic that is not heading for WAN, and the tunnel is not WAN.
  • MTU. Connections are made, small things work, large things hang. See Websites stall while loading.

What the configurator does about it

Every WireGuard interface has the switch Tunnel counts as LAN (management/DNS over VPN), on by default. It puts the tunnel interface in the LAN list, which is what lets the input rule pass you and lets you use the router as a DNS server. Switch it off and you get exactly the picture from step 4 above.

The firewall rules for the VPN are generated from the VPN section: an accept on the UDP port of every WireGuard interface, on 500 and 4500 plus ESP for IPsec, on 1701 inside IPsec for L2TP, and so on. You do not have to add those to the manual list.

For every road-warrior peer the tool writes a ready-made client configuration next to the script, with AllowedIPs, the DNS server and the endpoint in it. With no public address or hostname filled in you get a placeholder there, and the tool warns about it. A missing key pair or public key is reported too.

What the tool cannot check is whether your user's home network happens to use the same range as your office. For two locations in one site that check does exist; for a phone in a hotel it cannot. So pick a LAN range that nobody has by default; see Planning addresses.

When it is not your router

  • The network the client is on. Guest networks in hotels and companies often block UDP on high ports. Test on mobile data to rule that out.
  • The client has two VPNs. An always-on VPN from an employer beats yours.
  • The device you want to reach is off. Ping the router in the tunnel first, then the device.

Further reading: WireGuard, Remote access VPN and Firewall and NAT.

Want to try it right away? Open the configurator