8.1 KiB
Raw Permalink Blame History

WireGuard Server Setup Error Summary

This document summarizes the errors encountered while setting up a WireGuard VPN server on an EC2 instance, along with their causes and resolutions. The issues primarily relate to handshake failures between the client and server, stemming from configuration mismatches and network setup problems.

Error 1: Handshake Failure Due to Incorrect Peer Public Key

Description

The WireGuard tunnel failed to establish a handshake between the client and the EC2 server.

Cause

  • The server's [Peer] section in the configuration (/etc/wireguard/wg0.conf) contained an incorrect public key (4lr6dNMU0mFsBPVmuTUt3mRkbavaPRlm0pCFRe8aghQ=) that did not match the client's actual public key (f5oE/Nam9wRhk18zqa3nM43p1UlDggMi4ExLz37aEFo=), generated from the client's private key (+HdWG/o+XJJpzE6UH4GMNCsynnU/aUlG4EnCP0GwX2M=).
  • This mismatch prevented the server from authenticating the client's handshake attempts.

Resolution

  • Verified the client's public key using:
    echo "+HdWG/o+XJJpzE6UH4GMNCsynnU/aUlG4EnCP0GwX2M=" | wg pubkey
    
  • Updated the server's configuration to use the correct client public key:
    [Peer]
    PublicKey = f5oE/Nam9wRhk18zqa3nM43p1UlDggMi4ExLz37aEFo=
    AllowedIPs = 10.0.0.10/32
    
  • Restarted the WireGuard service:
    sudo wg-quick down wg0
    sudo wg-quick up wg0
    

Error 2: Incorrect Network Interface in tcpdump

Description

Attempting to capture packets using tcpdump resulted in an error:

tcpdump: eth0: No such device exists

Cause

  • The EC2 instance's primary network interface was not eth0 (likely ens5 or similar, common in modern Ubuntu AMIs on AWS).
  • The incorrect interface name prevented verification of whether client handshake packets were reaching the server.

Resolution

  • Recommended identifying the correct network interface using:
    ip link
    
  • Suggested rerunning tcpdump with the correct interface (e.g., ens5):
    sudo tcpdump -i ens5 udp port 51820
    
  • This step is pending confirmation of the correct interface name from the user.

Error 3: Incorrect Peer Configuration in Server

Description

The server's configuration included a [Peer] section with its own public key and client-like settings:

[Peer]
PublicKey = W3WWqz6ZnMafvut1jqkgOb+JTHFxq8TpzKpZjlJWHkY=
AllowedIPs = 10.0.0.10/32, 192.168.8.0/24
Endpoint = 63.176.104.56:51820
PersistentKeepalive = 25

Cause

  • The peer PublicKey matched the server's own public key, which is invalid (a server cannot be its own peer).
  • The Endpoint and PersistentKeepalive settings are typically client-side, indicating a mix-up between client and server roles.
  • This configuration caused handshake failures because the server was misconfigured to connect to itself or an incorrect peer.

Resolution

  • Removed the incorrect [Peer] section and replaced it with the correct client public key (f5oE/Nam9wRhk18zqa3nM43p1UlDggMi4ExLz37aEFo=).
  • Removed Endpoint and PersistentKeepalive from the server configuration, as they are not needed unless the server initiates connections to another peer.
  • Provided a corrected server configuration:
    [Interface]
    PrivateKey = OC73dpFa7AfcYksjnbupJJUTyWtOQ70+2d9Q/t/jIFg=
    Address = 10.0.0.1/24
    ListenPort = 51820
    
    [Peer]
    PublicKey = f5oE/Nam9wRhk18zqa3nM43p1UlDggMi4ExLz37aEFo=
    AllowedIPs = 10.0.0.10/32
    

Error 4: Potential Endpoint IP Mismatch

Description

The client configuration specified an endpoint of 34.243.156.239:51820, while one of the server configurations referenced 63.176.104.56:51820, indicating a potential mismatch in the server's public IP.

Cause

  • If the EC2 instance's public IP is not 34.243.156.239, the client cannot reach the server, leading to handshake failures.
  • The discrepancy between the two IPs suggests uncertainty about the server's actual public IP.

Resolution

  • Recommended verifying the EC2 instance's public IP:
    curl ifconfig.me
    
  • If the IP is 63.176.104.56, update the client configuration:
    Endpoint = 63.176.104.56:51820
    
  • If the IP is 34.243.156.239, keep the client configuration unchanged.
  • This step is pending confirmation of the server's public IP from the user.

Error 5: Missing PersistentKeepalive in Client Configuration

Description

The client configuration lacked PersistentKeepalive, which is necessary when the client is behind a NAT (e.g., home or mobile network).

Cause

  • Without PersistentKeepalive, the client's NAT mapping may close, preventing the server from responding to handshake attempts.

Resolution

  • Added PersistentKeepalive = 25 to the client configuration:
    [Interface]
    PrivateKey = +HdWG/o+XJJpzE6UH4GMNCsynnU/aUlG4EnCP0GwX2M=
    Address = 10.0.0.10/24
    DNS = 1.1.1.1, 8.8.8.8
    
    [Peer]
    PublicKey = W3WWqz6ZnMafvut1jqkgOb+JTHFxq8TpzKpZjlJWHkY=
    AllowedIPs = 0.0.0.0/0
    Endpoint = 34.243.156.239:51820
    PersistentKeepalive = 25
    
  • Instructed to update this in the WireGuard app.

Error 6: Potential Firewall or Security Group Issues

Description

The handshake failure could be due to packets not reaching the server, as tcpdump couldnt be tested on the correct interface.

Cause

  • The AWS security group or local firewall (e.g., ufw or iptables) may be blocking UDP port 51820.
  • The incorrect interface name (eth0) prevented verification of incoming packets.

Resolution

  • Recommended ensuring the AWS security group allows inbound UDP traffic on port 51820:
    • Type: Custom UDP
    • Protocol: UDP
    • Port Range: 51820
    • Source: 0.0.0.0/0 (or a specific IP range)
  • Suggested allowing UDP 51820 in the local firewall:
    sudo ufw allow 51820/udp
    
    Or with iptables:
    sudo iptables -A INPUT -p udp --dport 51820 -j ACCEPT
    
  • Pending confirmation of firewall settings and correct interface for packet capture.

Error 7: Missing IP Forwarding and NAT Configuration

Description

The client uses AllowedIPs = 0.0.0.0/0 for full-tunnel routing, but the server may not be configured to forward traffic.

Cause

  • Without IP forwarding and NAT, the server cannot route the client's traffic to the internet, potentially affecting connectivity post-handshake.

Resolution

  • Enabled IP forwarding:
    sudo sysctl -w net.ipv4.ip_forward=1
    echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
    
  • Configured NAT (assuming interface ens5):
    sudo iptables -A FORWARD -i wg0 -j ACCEPT
    sudo iptables -t nat -A POSTROUTING -o ens5 -j MASQUERADE
    sudo apt-get install iptables-persistent
    sudo dpkg-reconfigure iptables-persistent
    
  • Noted that the correct interface (e.g., ens5) needs to be confirmed via ip link.

Additional Notes

  • Pending Information: The handshake status (sudo wg show), server public IP (curl ifconfig.me), and correct network interface (ip link) are still needed to confirm resolution of network-related issues.
  • Testing Recommendations:
    • After applying the corrected configurations, check the handshake:
      sudo wg show
      
    • Test connectivity from the client:
      ping 10.0.0.1
      curl ifconfig.me
      
  • Debugging Steps: If issues persist, capture packets on the correct interface and check WireGuard logs:
    sudo tcpdump -i ens5 udp port 51820
    sudo journalctl -u wg-quick@wg0 -f
    

Final Configurations

Client Configuration (wg-client.conf)

[Interface]
PrivateKey = +HdWG/o+XJJpzE6UH4GMNCsynnU/aUlG4EnCP0GwX2M=
Address = 10.0.0.10/24
DNS = 1.1.1.1, 8.8.8.8

[Peer]
PublicKey = W3WWqz6ZnMafvut1jqkgOb+JTHFxq8TpzKpZjlJWHkY=
AllowedIPs = 0.0.0.0/0
Endpoint = 63.176.104.56:51820
PersistentKeepalive = 25

Server Configuration (wg0.conf)

[Interface]
PrivateKey = OC73dpFa7AfcYksjnbupJJUTyWtOQ70+2d9Q/t/jIFg=
Address = 10.0.0.1/24
ListenPort = 51820

[Peer]
PublicKey = f5oE/Nam9wRhk18zqa3nM43p1UlDggMi4ExLz37aEFo=
AllowedIPs = 10.0.0.10/32

This summary captures all identified errors and their resolutions, providing a clear path to a functional WireGuard VPN setup.