WireGuard Handshake Succeeds but Traffic Does Not Pass

Confirm the handshake and the transfer counters

Run wg show for the interface and read the latest-handshakes and transfer fields. The wg(8) man page documents the latest-handshakes field as the time of the most recent authenticated handshake and the transfer field as the bytes sent and received. A non-zero recent handshake with non-moving transfer counters indicates that the tunnel is up at the cryptographic layer but traffic is not entering or leaving the interface.[1]

wg show <iface>

Record each peer's AllowedIPs and the local interface address

Run wg show with the allowed-ips field for the interface, and note the Address entry from the wg-quick configuration. The wg(8) man page describes AllowedIPs as both the allowed incoming addresses and the routing target for outgoing traffic, and the wg-quick(8) man page describes the routes that wg-quick infers from AllowedIPs.[1][2]

wg show <iface> allowed-ips

Inspect the route for the intended destination

Use the system route table (for example ip route) to confirm whether a route for the intended destination points at the WireGuard interface or, when wg-quick handles a default route, whether the policy routing rule and fwmark match the tunnel. The wg-quick(8) man page states that wg-quick infers routes from AllowedIPs and uses ip-rule to handle overriding of the default gateway when one of the routes is 0.0.0.0/0 or ::/0.[2]

Do not change the forwarding or NAT state before classification

Do not enable IPv4 forwarding, change sysctl values, or insert iptables or nftables rules before classifying whether the issue is a universal WireGuard configuration problem or a platform-specific gateway problem. A host network change made before classification can remove the only remote-access path or weaken the host firewall.[4]

1. Classify the universal vs platform-specific boundary

Determine whether the issue is a universal WireGuard configuration problem (AllowedIPs and the routes inferred from it) or a platform-specific VPN-gateway problem (forwarding and source-NAT or masquerade on the routing host). The wg(8) and wg-quick(8) man pages ground the universal boundary; the Canonical Ubuntu Server how-to grounds the platform-specific gateway boundary for the Ubuntu Server default-gateway topology.[1][2][4]

2. Verify AllowedIPs coverage on both peers

Compare the intended destination networks with the AllowedIPs entry on each peer. The wg(8) man page states that AllowedIPs is the list of IP addresses with CIDR masks from which incoming traffic for this peer is allowed and to which outgoing traffic for this peer is directed. A missing or narrow entry on either side means the peer will not direct the matching traffic through the tunnel.[1]

3. Verify the route for the intended destination

Confirm that a route for the intended destination exists and points at the WireGuard interface, or, when the tunnel carries a default route, that the wg-quick policy routing rule and fwmark match the tunnel. The wg-quick(8) man page states that wg-quick infers all routes from the list of peers' allowed IPs and automatically adds them to the system routing table, with separate handling for the default route.[2]

4. If the routing host forwards traffic, verify forwarding and NAT

When the deployment is a VPN gateway where the routing host is expected to forward or NAT traffic for peers, verify IPv4 forwarding and the source-NAT or masquerade rule. The Canonical Ubuntu Server WireGuard default-gateway how-to documents enabling net.ipv4.ip_forward via a sysctl drop-in and adding an iptables MASQUERADE rule for the WireGuard subnet, and notes that the outgoing interface name must match the host. Other distributions and firewall backends use their own documented procedures; this page does not claim a universal command set.[4]

Correct AllowedIPs on both peers and re-apply the configuration

Edit the wg-quick configuration on each peer so that the AllowedIPs entry on the server covers the intended client tunnel address and the entries on the client cover the intended remote networks, and re-apply the configuration. The wg(8) man page documents the syncconf subcommand as reading back the existing configuration and only making changes that are explicitly different, without disrupting current peer sessions; the wg-quick(8) man page documents the strip subcommand to output a configuration file with wg-quick-specific options removed, suitable for use with wg syncconf. This correction changes the WireGuard interface configuration; it does not repair the host system route table.[1][2]

wg syncconf <iface> <(wg-quick strip <iface>)

If AllowedIPs is correct but the expected system route is missing: preserve route evidence and hand off

When AllowedIPs covers the intended destination but the expected route for that destination does not point at the WireGuard interface, or the wg-quick policy routing rule and fwmark for a default route do not match the tunnel, preserve the route-table output, the wg show output, the wg-quick configuration, the policy-rule and fwmark state, and the deployment distribution before any change. Do not use wg syncconf as a route repair: the wg(8) boundary is interface configuration, while wg-quick(8) describes interface setup and routes inferred from AllowedIPs. This page does not prescribe ip route mutations or a generic Linux route recipe; send the sanitized evidence to the operator for a topology-specific repair.[1][2]

If the universal configuration is correct and the host does not forward: investigate the destination path

When the deployment is a pure peer-to-peer tunnel (the host does not forward traffic for the peer), the wg(8) and wg-quick(8) man pages do not require any extra forwarding or NAT. If the universal WireGuard configuration is correct and the intended traffic still does not flow, verify the destination reachability from the tunnel endpoint on a different path, the destination peer firewall, and the application listener before changing WireGuard settings.[1][2]

Ubuntu Server default-gateway topology: enable IPv4 forwarding and add a masquerade rule for the tunnel subnet

This solution applies specifically to the Ubuntu Server default-gateway topology described in the Canonical how-to. On the routing host, create a sysctl drop-in (for example /etc/sysctl.d/70-wireguard-routing.conf) containing net.ipv4.ip_forward = 1 and apply it with sudo sysctl -p /etc/sysctl.d/70-wireguard-routing.conf -w. Record the current value of net.ipv4.ip_forward before any change. Add an iptables MASQUERADE rule that matches the WireGuard subnet and the actual outgoing interface on the host. The Canonical how-to notes that the interface name must match the host. Other distributions and firewall backends (nftables, firewalld, and so on) use their own documented procedures; do not copy the Ubuntu iptables example into a deployment that uses a different backend. Forwarding and firewall changes are host network changes; require console or out-of-band access, a saved configuration, and a verified restoration path before proceeding.[4]

iptables -t nat -A POSTROUTING -s <vpn-subnet> -o <outgoing-iface> -j MASQUERADE

If forwarding and masquerade are already configured: verify the tunnel subnet and the outgoing interface

When the routing host already has IPv4 forwarding and a source-NAT or masquerade rule, verify that the rule matches the actual WireGuard subnet and the actual outgoing interface, and not a different subnet or interface. The Canonical Ubuntu Server WireGuard default-gateway how-to notes that the interface name must match the host. A rule that references a different interface or a different subnet does not forward the traffic that arrives on the tunnel.[4]

If the boundary cannot be classified: preserve the evidence

Record the wg show output for both peers, the wg-quick configuration on each side, the system route table, the value of net.ipv4.ip_forward on the routing host, the existing iptables or nftables NAT and FORWARD rules, and the deployment distribution and firewall backend. Send the sanitized evidence to the operator before any further change. The wg(8) and wg-quick(8) man pages and the Canonical Ubuntu Server how-to do not describe a procedure for a tunnel whose boundary cannot be classified.[1][2][4]

Before any separately scoped host network or firewall change

Planning boundary only. The operator must consider the current sysctl values, the current iptables or nftables state, the host firewall, the deployment distribution and firewall backend, and the recovery access path. This page does not disable the host firewall, copy the Ubuntu iptables example into a non-Ubuntu deployment, or assume the outgoing interface name.[4]