Troubleshooting WireGuard with Tcpdump

If you see nothing from tcpdump on Endpoint A, you have a routing problem: Endpoint A doesn’t have a usable route for Endpoint B’s IP address of 192.168.200.22. First run the wg command on Endpoint A to double-check that its WireGuard interface is up, and that 192.168.200.22 is included its AllowedIPs address ranges; then try running the ip route and ip rule commands on Endpoint A to debug its routes and policy-routing rules.

If you see an interface name other than wg0 in this entry, you have a routing problem: Endpoint A isn’t routing Endpoint B’s IP address of 192.168.200.22 to WireGuard. First run the wg command on Endpoint A to double-check that its WireGuard interface is up, and that 192.168.200.22 is included its AllowedIPs address ranges; then try running the ip route and ip rule commands on Endpoint A to debug its routes and policy-routing rules.

First double-check the A1 entry for problems; if it looks good, but Endpoint A and Host β haven’t yet successfully completed a handshake, and you don’t see this entry, you may have a WireGuard configuration problem: Run the wg command on Endpoint A to check that you have an Endpoint set for Host β (and that it is Host β’s correct public IP address and WireGuard listen port: 203.0.113.2:51822 in this example).

If you see a destination IP address other than Host β’s public address of 203.0.113.2, or a destination port other than Host β’s WireGuard listen port of 51822, you have a WireGuard configuration problem: Correct the Endpoint setting for Host β in Endpoint A’s WireGuard config file, and restart the WireGuard interface.

If this packet’s data length is not exactly 148 bytes, it’s not a WireGuard handshake initiation packet. Most likely, a WireGuard handshake between Endpoint A and Host β has already occurred in last 2 minutes, and this is actually an encrypted WireGuard data packet — the A4 tcpdump entry.

If you see the exact same A2 entry repeated about 20 times in a row, spaced 5 seconds apart, first check the B1 and B2 tcpdump entries on Host β. If they are both present and look good, follow the advice under the “No tcpdump entry” heading for the A3 entry.

First double-check the A2 entry on Endpoint A for problems; if it looks good, but Endpoint A and Host β haven’t yet successfully completed a handshake, and you don’t see this entry, you either have a firewall problem or a routing problem in the networks between Endpoint A and Host β: Try checking any firewalls or routers in front of Host β to which you have access. Make sure any such firewalls allow forwarding new connections at least to Host β’s UDP port 51822 and public IP address of 203.0.113.2 from Endpoint A’s public IP address of 198.51.100.1.

If this packet’s data length is not exactly 148 bytes, it’s not a WireGuard handshake initiation packet. Most likely, a WireGuard handshake between Endpoint A and Host β has already occurred in last 2 minutes, and this is actually an encrypted WireGuard data packet — the B3 tcpdump entry.

If Endpoint A and Host β haven’t yet successfully completed a handshake, and you don’t see this entry, you either have a WireGuard configuration problem, or a firewall problem on Host β: First, run the wg command on Host β to check that you have a peer configured for Endpoint A.

justin@endpoint-a:~$ sudo wg
interface: wg0
  public key: /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
  private key: (hidden)
  listening port: 51821

peer: fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
  endpoint: 203.0.113.2:51822
  allowed ips: 192.168.200.0/24
  transfer: 0 B received, 148 B sent

justin@host-b:~$ sudo wg
interface: wg0
  public key: fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
  private key: (hidden)
  listening port: 51822

peer: /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
  allowed ips: 10.0.0.1/32

If you see an interface name other than eth0 in this tcpdump entry (ie a different interface than the B1 entry), you may have a routing problem: Host β isn’t routing Endpoint A’s public IP address of 198.51.100.1 out the same interface from which Endpoint A’s packets are coming in. Unless this is an deliberate routing choice you have made, try running the ip route and ip rule commands on Host β to debug its routes and policy-routing rules.

If this packet’s data length is not exactly 92 bytes, it’s not a WireGuard handshake response packet. Most likely, a WireGuard handshake between Endpoint A and Host β has already occurred in last 2 minutes, and this is some other packet. If this entry matches the example above perfectly except for the data length, then it is actually an encrypted WireGuard data packet being sent from Host β to Endpoint A — the B8 tcpdump entry.

First double-check the B2 entry on Host β for problems; if it looks good, but Endpoint A and Host β haven’t yet successfully completed a handshake, and you don’t see this entry, you either have a firewall problem or a routing problem in the networks between Host β and Endpoint A: Try checking any firewalls or routers in front of Endpoint A to which you have access. Make sure any such firewalls allow forwarding established connections at least to Endpoint A’s UDP port 51821 and public IP address of 198.51.100.1 (or LAN address of 192.168.1.11 for the path between Endpoint A and its NAT router) from Host β’s public IP address of 203.0.113.2.

If this packet’s data length is not exactly 92 bytes, it’s not a WireGuard handshake response packet. Most likely, a WireGuard handshake between Endpoint A and Host β has already occurred in last 2 minutes, and this is actually an encrypted WireGuard data packet — the A5 tcpdump entry.

If you see the exact same A2 and A3 entries repeated one after the other about 20 times, you have a firewall problem on Endpoint A: Try running the iptables-save and nft list ruleset commands on Endpoint A to debug problems with its own host-based firewall. Make sure Endpoint A’s own firewall allows inbound access for established connections to its wlan0 interface, at least for its UDP port 51821, from Host β’s public IP address of 203.0.113.2.

First double-check the B2 entry on Host β for problems; if it looks good, but Endpoint A and Host β haven’t yet successfully completed a handshake, and you don’t see this entry, you have a firewall problem on Endpoint A: Try running the iptables-save and nft list ruleset commands on Endpoint A to debug problems with its own host-based firewall. Make sure Endpoint A’s own firewall allows inbound access for established connections to its wlan0 interface, at least for its UDP port 51821, from Host β’s public IP address of 203.0.113.2.

This packet’s data length will vary based on the underlying data it’s encrypting, but if its length is exactly 148 bytes, it’s probably actually a WireGuard handshake attempt, and this is actually another A2 entry. If WireGuard on Endpoint A does not receive a successful handshake response, you will see about 20 A2 entries, spaced 5 seconds apart, as WireGuard tries again and again to initiate a handshake with Host β. If you see these entries interspersed with corresponding A3 entries, you have a firewall problem on Endpoint A (see above). If don’t see any A3 entries, you have a firewall or routing problem between Host β and Endpoint A (see A3).

This packet’s data length will vary based on the underlying data it’s encrypting, but if its length is exactly 148 bytes, it’s probably actually a WireGuard handshake attempt, and this is actually another B1 entry. If WireGuard on Endpoint A does not receive a successful handshake response, you may see about 20 B1 entries, spaced 5 seconds apart, as WireGuard tries again and again to initiate a handshake with Host β. If you see these entries interspersed with corresponding B2 entries, you likely have a firewall or routing problem between Host β and Endpoint A (see A3). If you don’t see any B2 entries, you likely have a firewall or WireGuard configuration problem on Host β (see B1).

If you see the B3 entry, but not this entry, you have a WireGuard configuration problem: Run the wg command on Host β to check that its AllowedIPs setting for Endpoint A includes Endpoint A’s WireGuard address of 10.0.0.1.

If you see the B4 entry, but not this entry, you either have a firewall problem or a routing problem on Host β. First run the sysctl net.ipv4.conf.all.forwarding command on Host β to check that you’re allowing any IPv4 packet forwarding at all (the output should have a value of 1, indicating that forwarding is allowed).

If you’re expecting to use SNAT (Source Network Address Translation, aka packet masquerading) with this connection, you should see the source address change between the B4 entry and this one (in this example, we’re using SNAT to translate Endpoint A’s WireGuard address of 10.0.0.1 to Host β’s own LAN address of 192.168.200.2). If it’s not being translated to the correct address, you have a firewall problem: Try running the iptables-save and nft list ruleset commands on Host β to debug problems with its firewall rules.

If you’re expecting to use DNAT (Destination Network Address Translation, aka port forwarding) with this connection, you should see the destination address change between the B4 entry and this one (however, in this example, we’re not using DNAT, so we should see no changes). If it’s not being translated to the correct address, you have a firewall problem: Try running the iptables-save and nft list ruleset commands on Host β to debug problems with its firewall rules.

First double-check the B5 entry for problems; if it looks good, you either have a firewall problem or a routing problem at the Site B LAN (or in the networks between Host β and Endpoint B, if they are not simply on the same LAN), or on Endpoint B itself.

If you see the B6 entry, but not this entry, you have a firewall problem on Host β. Try running the iptables-save and nft list ruleset commands on Host β to debug problems with its firewall (the output should show that it allows at minimum the forwarding of established connections to Endpoint A’s WireGuard address of 10.0.0.1, using Host β’s WireGuard interface wg0, from Endpoint B’s LAN address of 192.168.200.22, using Host β’s LAN interface eth1).

If you see an interface name other than wg0 in this entry, you have a routing problem: Host β isn’t routing Endpoint A’s WireGuard address of 10.0.0.1 to WireGuard. Try running the ip route and ip rule commands on Host β to debug its routes and policy-routing rules.

This packet’s data length will vary based on the underlying data it’s encrypting, but if its length is exactly 92 bytes, it’s probably actually a WireGuard handshake response, and this is actually another A3 entry. If you see multiple handshake-initiation A2 entries interspersed with multiple handshake-response A3 entries, you have a firewall problem on Endpoint A: Try running the iptables-save and nft list ruleset commands on Endpoint A to debug problems with its own host-based firewall. Make sure Endpoint A’s own firewall allows inbound access for established connections to its wlan0 interface, at least for its UDP port 51821, from Host β’s public IP address of 203.0.113.2.

If you see the same exact A5 and A6 entries repeated several times (and no other entries besides keepalive entries), you have a firewall problem on Endpoint A: Try running the iptables-save and nft list ruleset commands on Endpoint A to debug problems with its firewall (the output should show that it allows at minimum established connections incoming to Endpoint A’s WireGuard interface wg0 from Endpoint B’s LAN address of 192.168.200.22).

If this tcpdump entry looks good, but the underlying application (eg curl) does not report receiving anything, you have a firewall problem on Endpoint A: Try running the iptables-save and nft list ruleset commands on Endpoint A to debug problems with its firewall (the output should show that it allows at minimum established connections incoming to Endpoint A’s WireGuard interface wg0 from Endpoint B’s LAN address of 192.168.200.22).