WireGuard on OMV: One-Way Connection Works, Configuration Adjustments

Understanding the One-Way Symptom

When a WireGuard client connects to an OpenMediaVault (OMV) server but can only send data without receiving any back, the issue is almost always related to how the operating system handles return traffic. In a properly configured setup, packets sent from the client to the server should be routed to the destination, and the response packets should flow back through the VPN tunnel to the client. If this reverse path fails, the client appears online but cannot browse websites or access network resources.

This symptom often confuses users who see a successful handshake in the logs. The connection is established at Layer 3, but the routing table or firewall rules on the OMV host are blocking the return traffic. It is crucial to distinguish this from a "no internet" scenario where the client cannot reach any external IPs; here, the client might ping the gateway but nothing comes back.

Enabling IP Forwarding

The first step in resolving connectivity issues is ensuring that the Linux kernel is allowed to forward packets between interfaces. OpenMediaVault runs on Debian, which disables IP forwarding by default for security reasons. However, a VPN server must act as a router for its clients.

To enable this permanently, you need to modify the sysctl configuration. Open a terminal on your OMV server and edit the file /etc/sysctl.conf. Add or uncomment the following line:

net.ipv4.ip_forward = 1

After saving the file, apply the changes immediately by running the command sysctl -p. You can verify that forwarding is active by checking the value with cat /proc/sys/net/ipv4/ip_forward; it should output 1. Without this setting, even if your firewall rules are correct, the kernel will drop incoming packets destined for other interfaces, resulting in a one-way connection.

Configuring the Firewall Rules

OpenMediaVault uses a graphical interface for firewall management, often leveraging iptables or nftables under the hood. The most common mistake is allowing inbound traffic on the WireGuard port (usually UDP 51820) but forgetting to allow forwarded traffic between the wg0 interface and the LAN interface (typically eth0 or ens3).

In the OMV web interface, navigate to System > Firewall. Ensure that there is a rule permitting traffic from the WireGuard subnet to your local LAN subnet. If you are using the command line, you can check current rules with iptables -L -n -v. Look for chains named FORWARD. You may need to add a rule similar to:

iptables -A FORWARD -i wg0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT

The first rule allows new connections from the VPN to the LAN. The second rule ensures that return traffic from the LAN to the VPN is accepted if it is part of an existing connection. This stateful inspection is critical for maintaining the bidirectional flow of data.

NAT Masquerading

If your goal is to give WireGuard clients access to the internet via the OMV server, you also need Network Address Translation (NAT). This hides the client's private IP behind the server's public IP. In OMV, this is often handled in the NAT section of the firewall settings. If not configured automatically when you added the WireGuard plugin, you must add a POSTROUTING rule:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Replace 10.8.0.0/24 with your actual WireGuard subnet and eth0 with your outgoing WAN interface. This ensures that responses from the internet are correctly routed back to the VPN gateway.

Verifying Client Configuration

Sometimes the issue lies not on the server, but in the client's configuration. Check the AllowedIPs field in your client's wg.conf file. If you want full tunnel access, this should be set to 0.0.0.0/0 (IPv4) and ::/0 (IPv6). If it is set incorrectly, such as only pointing to a specific subnet, the client will not route general traffic through the VPN, leading to apparent connectivity failures.

Additionally, verify that the client's DNS settings are appropriate. If the client is using a public DNS like Google's 8.8.8.8, but the server does not have proper routing or NAT for those queries, you might experience timeouts. Consider setting the client DNS to the OMV server's IP or a reliable resolver accessible from the LAN.

Troubleshooting Steps

If the above steps do not resolve the issue, perform these diagnostic checks:

• Ping from Server to Client: SSH into the OMV server and try pinging the client's WireGuard IP address. If this fails, the firewall is definitely blocking the return path.
• Check Logs: View the system logs with dmesg | grep wireguard or check /var/log/syslog for dropped packets.
• Review Subnet Conflicts: Ensure your WireGuard subnet does not overlap with your local LAN subnet. For example, if your LAN is 192.168.1.0/24, do not use 192.168.1.x for WireGuard.

For more advanced scenarios involving multiple clients or complex routing, consider reading our guide on Troubleshooting WireGuard Client-to-Client Communication Issues to understand peer isolation settings.

Frequently Asked Questions

Why can I ping the server but not browse the web?

This indicates that basic connectivity exists, but routing or NAT is misconfigured. Ensure that net.ipv4.ip_forward` is set to 1 and that you have a NAT masquerade rule in place for the WireGuard subnet. Without NAT, return traffic from the internet won't know how to find the client behind the private IP.