Ever tried combining a transparent proxy with a WireGuard VPN client, aiming to secure all local traffic through a remote VPS, only to find that enabling UFW (Uncomplicated Firewall) breaks Internet connectivity? If you’ve found yourself in this situation, you’re not alone. This article unpacks the complexities and offers a simple solution, often overlooked in UFW’s default settings.
In my quest for enhanced online privacy and security, I turned to WireGuard, the fast and modern VPN protocol. I decided to use a Raspberry Pi as a WireGuard client, transforming it into a transparent proxy situated between my Wi-Fi router and ISP modem. This setup allows all my local devices—be it a MacBook, iPad, or iPhone—to automatically route their traffic through a WireGuard VPN tunnel. The end-point of this tunnel is a remote VPS located in Amsterdam, thereby making it appear as if all my Internet traffic originates from there.
Choosing DigitalOcean for my VPS needs, I was able to establish a successful WireGuard VPN connection between my Raspberry Pi and the remote server. This was verified by executing the
sudo wg show command on both ends. However, a significant issue reared its head—none of the devices connected to the Raspberry Pi could access the Internet when UFW was enabled. This was puzzling, as the primary role of UFW is to provide an uncomplicated way to manage iptables, the powerful firewall built into the Linux kernel.
Disclaimer: I want to make it clear that I’m not promoting DigitalOcean, nor am I being compensated for writing this article or endorsing their services. I’ve been using DigitalOcean for five years and have found its services beneficial for my specific needs, which is why I’ve chosen to share this information.
In this article, I will elucidate the steps required to fix this problem. The solution, as you’ll see, involves a few adjustments to the UFW settings on the Raspberry Pi. But before we delve deeper into solving the problem, it’s important to clarify some networking nuances related to this setup. If you’re not interested in the details and simply want to resolve the issue, feel free to skip ahead to the “Solution” section.
While the WireGuard traffic between the Raspberry Pi and the remote VPS uses UDP port 51820, that’s just for the VPN tunnel itself. All other traffic from your local devices like MacBook, iPad, or iPhone that routes through the Wi-Fi router to the Raspberry Pi will be on various other ports, depending on the services being accessed (such as HTTP on port 80, HTTPS on port 443, DNS on port 53, etc.).
In this transparent proxy configuration, the Raspberry Pi acts more like a gateway rather than a server that “listens” on specific ports. Its primary role is to forward the traffic from your local devices through the WireGuard tunnel to your remote VPS. That’s why you generally don’t need UFW rules for allowing incoming traffic on ports like 80, 443, and 53 on the Raspberry Pi itself. These ports are not being “served” by the Raspberry Pi; they’re merely being forwarded through it.
However, this forwarding behavior can be disrupted by UFW, which might block it by default. The solution usually involves modifying the UFW “before.rules” file to explicitly permit packet forwarding. This is separate from the typical UFW rules that allow incoming traffic on specific ports, and we will go into the details of this in the subsequent sections.
Your setup may not exactly mirror mine. For example, you could be using a different machine as your transparent proxy, or you might be connecting to a WireGuard server in a different location. Even the issue of UFW disrupting your Internet access could manifest in various setups. However, the core problem explored in this article—and its proposed solution—should apply broadly, regardless of these individual differences.
The solution is surprisingly straightforward. The root of the issue often resides in the default settings of UFW (Uncomplicated Firewall), which can interfere with the transparent routing of network traffic through the WireGuard tunnel. To resolve this, adjustments will need to be made to UFW’s settings on the machine acting as the transparent proxy with WireGuard VPN client.
Enable IP forwarding at the system level by editing
sudo nano /etc/sysctl.conf
Un-comment or add the following line:
Save and close the file.
Apply the sysctl changes:
sudo sysctl -p
Edit UFW’s before.rules file:
sudo nano /etc/ufw/before.rules
Add the following lines at the top of the file to enable IP forwarding:
# Allow traffic forwarding -A ufw-before-forward -j ACCEPT
Save and close the file.
Reload UFW to apply the changes:
sudo ufw reload
By doing this, you’re allowing your machine acting as the transparent proxy with WireGuard VPN client (in my case, a Raspberry Pi) to forward packets from your local network to the external network via the WireGuard tunnel.
Addressing UFW-induced Internet connectivity issues in a WireGuard-enabled transparent proxy setup (in my case, a remote VPS serves as the WireGuard server) can initially appear intimidating. You may find yourself grappling with a loss of Internet access on your local devices and feel uncertain about how to proceed. However, the good news is that the solution is quite simple and involves just a few tweaks to UFW’s default settings. By following this guide, your transparent proxy should now be fully operational, allowing all connected devices to securely access the Internet via your remote VPS, without any disruptions.
I hope this article has helped you in resolving your WireGuard-enabled transparent proxy and UFW-related challenges in your setup. If this article has been helpful, please feel free to leave a comment
Thank you for taking the time to read this guide. May your network continue to be both secure and efficient, supported by a well-configured UFW!