wireguard service is active and that your .conf file resides in /etc/wireguard/ with read permissions for all users to ensure the daemon can parse the interface settings correctly.
Verify Kernel Module and Service Status
The most common cause for a complete lack of connectivity on Arch Linux is that the WireGuard kernel module has not been loaded into the running kernel. Unlike some other distributions, Arch requires explicit loading of this module before the service can function. You must check if the module is present by running lsmod | grep wireguard. If the output is empty, the module is not loaded.
To load it temporarily, use the command sudo modprobe wireguard. To make this persistent across reboots, create a file in /etc/modules-load.d/ named wireguard.conf containing the word wireguard. Once the module is active, you should check the status of the systemd service using systemctl status [email protected], replacing [email protected] with your actual interface name like wg0. If the service fails to start, the journal logs will provide specific error messages regarding missing keys or invalid syntax.
Check Configuration File Permissions and Location
WireGuard is strict about file permissions for security reasons. The private key must be kept secret, and the configuration file must be readable by the system but writable only by root. If the permissions are too open (e.g., world-writable), the service may refuse to start or apply the configuration silently. Ensure your configuration file in /etc/wireguard/ has permissions set to 600 or 644. You can adjust this using sudo chmod 600 /etc/wireguard/wg0.conf.
Additionally, verify that the file is located exactly in /etc/wireguard/. Arch Linux expects the configuration files to reside here rather than in /usr/lib/ or user directories. If you have moved the file, update the service unit or symlink it correctly. A common mistake is having a typo in the filename or placing it in a subdirectory without updating the service path. Run wg showconf wg0 to test if the parser can read the file without errors. This command dumps the current configuration from the file, allowing you to spot syntax issues like missing brackets or incorrect IP addresses.
Validate Firewall Rules and Port Forwarding
Even if the service is running, external connections will fail if the firewall blocks UDP traffic. WireGuard typically uses port 51820 by default. On Arch, you might be using iptables, nftables, or a frontend tool like ufw. Check your active rules to ensure UDP port 51820 is accepted on both input and forward chains. For iptables, the rule should look like -A INPUT -p udp --dport 51820 -j ACCEPT.
If you are behind a NAT router, remember that the public IP address in your configuration must match the router's public IP, and port forwarding must be enabled on the router itself. However, if you are connecting locally between two peers, you do not need port forwarding, but you do need local firewall rules to allow the traffic. See our guide on Route all internet traffic through Wireguard peer for more details on managing routing tables alongside firewall settings.
Testing Connectivity Internally
Before testing external access, verify internal peer communication. Use wg quick up wg0 to bring up the interface. Then, ping the peer's virtual IP address. If the ping works, the tunnel is established, and the issue is likely network-level (firewall/NAT). If the ping fails, check the AllowedIPs field in your configuration. This field determines which traffic is encrypted and sent through the tunnel. If it is set incorrectly, packets may be routed out the wrong interface.
Debugging with Logs and Tools
When standard checks fail, use journalctl -u [email protected] -f to watch logs in real-time while attempting to connect. Look for errors related to "invalid key" or "no route to host." Also, ensure that net.ipv4.ip_forward=1 is set in /etc/sysctl.conf if you intend to route traffic between networks. Without IP forwarding enabled, the Linux kernel will drop packets trying to pass between interfaces.
For advanced troubleshooting, consider checking for conflicts with other VPN clients or network managers that might be interfering with the wg0 interface. NetworkManager sometimes disables interfaces that are not managed by it. You can configure NetworkManager to ignore WireGuard interfaces by adding them to the unmanaged-devices list in its configuration. This prevents accidental disconnection during network state changes.
Frequently Asked Questions
Why does my WireGuard interface show as down even after starting the service?
This usually indicates a failure in parsing the configuration file or a missing private key. Check the journal logs for specific syntax errors or permission denied messages. Ensure the private key in the config matches the one generated during setup.
Can I use WireGuard on Arch without systemd?
While technically possible, it is highly discouraged. Arch Linux relies heavily on systemd for service management. Using alternative init systems requires manual scripting to handle interface bringing and dropping, which increases complexity and reduces reliability.
How do I fix "No Route to Host" errors in WireGuard?
This error means the underlying network cannot reach the peer's endpoint IP. Verify your server's public IP address and ensure port 51820 is forwarded correctly on your router. Also, check that your client's DNS is resolving the server hostname to the correct IP.
Does WireGuard support IPv6 on Arch Linux?
Yes, WireGuard fully supports IPv6. You can assign IPv6 addresses to peers and route IPv6 traffic through the tunnel. Ensure your server's firewall allows UDP traffic on IPv6 as well, and that your ISP provides IPv6 connectivity if you are relying on it for external access.
What should I do if my connection drops randomly?
Random drops often indicate MTU mismatches or unstable network conditions. Try lowering the MTU in your configuration to 1420 or 1380. Additionally, enable Keepalive in your config to detect dead links quickly. Refer to our article on Wireguard Peer Not Accessible by Other Peers for deeper insights into stability issues.