Configuring a WireGuard VPN on a Raspberry Pi
Configuring a WireGuard VPN on a Raspberry Pi
This discussion highlights a major concern about network configuration. The main issue revolves around IP forwarding settings and routing behavior. It’s important to note that internal VPN IP ranges should remain hidden from public-facing routers—they only exist within the tunnel. Your router shouldn’t be aware of them, as it only needs to maintain the connection between your device and the public port 51820.
The advice emphasizes verifying IPv4 forwarding is enabled on your system (check via `cat /proc/sys/net/ipv4/ip_forward`). Without this setting, routing will fail across interfaces. The tutorial’s “service” command essentially pushes a configuration into the kernel, and stopping it reverts to a permissive state. If you believe the VPN is working, treat it like normal routing between two interfaces.
Key steps include confirming IPv4 forwarding, inspecting routing tables before and after connecting to the VPN, and reviewing iptables configurations. Ensure only the necessary masking rules are in the nat table, and that mangle tables are empty. This helps avoid confusion and ensures proper network behavior.
Your firewall configuration appears to be functioning correctly. The output shows forwarding rules are active and routing seems intact. The ip add command lists valid interfaces, and the iptables logs confirm proper packet handling. It looks like everything is set up as intended.
It seems the issue might be related to NAT forwarding on your firewall. I’ll give a general overview, but if you’re stuck, sharing your router’s model will help us provide tailored guidance. Connections from your phone to your public IP via UDP port 51820 should be redirected to 192.168.0.16 on the same port. Some devices let you set up these rules immediately, while others require defining a service that specifies which ports are active. You’re likely looking for port forwarding or IP forwarding rules. When adding a rule, the system often creates an automatic rule to permit access at that port, though you may need to configure it manually in the firewall settings. If unsure, take a screenshot of your router’s interface or any relevant details and share it while hiding your public information. You can then configure your phone to connect through the VPN on your local network, confirming the correct settings for the router’s configuration.
I set up the device to connect to 192.168.0.16:51820 without any firewall rules, and it functions properly. The problem likely lies in the router's public-facing configuration.
The error with your NoIP configuration has been resolved, and a firewall rule was added as requested. The problem with not seeing your Samba server remains unresolved. Could you clarify what you're experiencing with it?
You might want to check your routing table after establishing the connection. It could help clarify whether iptables is handling SNAT correctly. Also, let me know the IP address you're trying to reach on the SMB server.
The permanence of the IP matters. If it stays fixed, you can proceed; otherwise, Samba needs special configuration. Once connected, the connection drops after a phone call. Think of these steps:
1. Set up iptables rules for the address.
2. Adjust rules when the device joins the network.
3. Ensure rules don’t block traffic after reconnection.
4. Test routing and firewall settings.
5. Document changes so they persist across sessions.
These two guidelines are stored in the standard tables and mainly serve to inform you about data flow into and out of wg0. They act as -nat rules: the first one blocks nothing since 10.147.167.0/24 isn't a valid IP address your Pi encounters, so it can be removed. The second targets other 192.168.0.x addresses on your network from your phone, which shouldn't impact this setup. In short, you could work around it with a forced redirect, but it should function as intended.