{
  "id": 1858219,
  "title": "UFW and WireGuard: the tunnel is up and nothing goes through",
  "url": "https://urgent.news/2026/08/19/ufw-and-wireguard-the-tunnel-is-up-and-nothing-goes-through",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-19T03:37:35.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/ricco020/ufw-and-wireguard-the-tunnel-is-up-and-nothing-goes-through-4lpo"
  },
  "original_language": "en",
  "account": "The UFW firewall and WireGuard tunnel are functioning properly, but traffic is unable to leave the tunnel and reach the internet. Many guides suggest opening UDP port 51820 in the firewall, but this does not address the underlying issue. The problem lies in the distinction between entering a machine and traversing it, which UFW handles differently. UFW allows packets to enter the server through port 51820, but it denies them from leaving through the FORWARD chain by default. To resolve this, four steps must be taken:\n\n1. Check IP forwarding by editing /etc/ufw/sysctl.conf and verifying the effective value with `sysctl net.ipv4.ip_forward`.\n2. Configure forwarding, either for a specific interface using `ufw route allow in on wg0 out on eth0` or globally with `DEFAULT_FORWARD_POLICY = ACCEPT` in /etc/default/ufw.\n3. Set up NAT for the tunnel interface by adding a block at the top of /etc/ufw/before.rules that includes `MASQUERADE` for the tunnel's subnet and interface.\n4. Ensure the correct interface name is used for the egress path, which may differ depending on the host.\n\nCommon mistakes include placing the NAT block after *filter, using a fixed interface name (e.g., eth0), and forgetting to reload UFW with `ufw disable && ufw enable`. Additionally, if WireGuard's PostUp/PostDown rules already include MASQUERADE, the NAT block is unnecessary. Once these steps are addressed, the tunnel should be able to successfully forward traffic to the internet.",
  "summary": "The tunnel comes up. wg show prints a recent handshake. The client has its address inside the tunnel. And not a single byte reaches the internet. Almost every guide answers this with \"open UDP 51820 in the firewall\". You already did that — it is why the handshake works at all. The problem is somewhere else, and UFW makes the distinction easy to miss: Entering a machine and traversing it are two…",
  "key_points": [
    "UFW and WireGuard tunnel functional but traffic blocked",
    "Four steps needed to resolve traffic issue",
    "NAT block required for egress path"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}