Hi all, I’m trying to have my rpi5 running raspberry OS communicate with the Internet only through the tun0 interface (vpn). For this I wanted to create a ufw ruleset. Unfortunately, I’ve hit a roadblock and I can’t figure out where I’m going wrong.
Can you help me discover why this ruleset doesn’t allow Internet communication over tun0? When I disable ufw I can access the Internet.
The VPN connection is already established, so it should keep working, right?
I hope you can help me out!
This is the script with the ruleset: sudo ufw reset
Set default policies
sudo ufw default deny incoming
sudo ufw default deny outgoing
Allow SSH access
sudo ufw allow ssh
Allow local network traffic
sudo ufw allow from 192.168.0.0/16
sudo ufw allow out to 192.168.0.0/16
Allow traffic through VPN tunnel
sudo ufw allow in on tun0
sudo ufw allow out on tun0
Add routing between interfaces (I read its necessary, not sure why?)
sudo ufw route allow in on tun0 out on wlan0
sudo ufw route allow in on wlan0 out on tun0
sudo ufw enable
You might be interested in my tool wg-lockdown. I mainly use it on desktops but it should work on servers as well, it’s just an nftables config after all. It also shouldn’t interfere with UFW though you might want to double-check with some of the networking experts here.
This is how I do it:
sudo ufw default deny outgoing sudo ufw default deny incoming sudo ufw allow out on tun0 from any to any sudo ufw allow out to VPN_IP_ADDRESS proto udpYou have to do the last line for all your VPN server ips or the initial DNS request will not go through. If you connect through udp.
*or the initial VPN connection request will not go through.
But mentioning DNS is a good point: if you’re addressing your VPN server by hostname, your client will need to be able to resolve that name somehow, either by running a DNS server elsewhere on your LAN and allowing traffic to the LAN (which is how I do it) or by allowing DNS traffic from the VPN client to a DNS server on the Internet.
Interesting, but by the time I apply the rules the VPN connection has already been established. Wouldn’t that remove the necessity for the last line?
Just to be clear this is a killswitch, that’s what you want right? So that it’s only possible to connect through the VPN (tun0). And if the VPN goes down your internet gets “killed” so you don’t leak your IP.
In that case you want to start ufw when you system starts, so you would need to whitelist your VPN but if your VPN is already connected it should work without whitelisting the IP I guess but never tried it since that’s not recommended.
Understood, yes it’s a kill switch. I’ll test your set of rules in a bit and let you know!
ufw is a firewall. Routing controls traffic flow. You want to set the default route of that machine to only use the tun0 interface. Random link explains
As a secondary step you can set your firewall to block any traffic trying to exit an interface I suppose, but it really shouldn’t be necessary.
For your other services on the local network for your subnet, just add a secondary route only for your subnet that uses your router as a gateway.
That makes sense, but it’s possible that the VPN connection drops for a second, and then it can’t re-establish it, right? How would I deal with that?
Remove default route using physical interface
Add route only to the IP of the VPN server
Bring up VPN
Add default route to traverse the tunnel
It wouldn’t be able to communicate with the internet, but would still be able to talk to your local network.
If that’s not specifically what you’re trying to do, and you don’t care if traffic might go out over your regular Internet connection, then you can create a fail over type situation where it will try and use a “backup” route to communicate to the internet if needed, though you’ll need to spend some time really making it pretty smooth: https://www.baeldung.com/linux/multiple-default-gateways-outbound-connections
I guess what I’m really trying to do is make sure that whatever happens, if the vpn fails (tun0), there is no more communication with the Internet.
That is called a “Kill Switch” try to search for that.
Then the first setup does that.
Except that that set of rules doesn’t work, or do you mean defining a default gateway?
The default gateway. If it’s not passing traffic, your machine doesn’t go looking elsewhere for routes that work. Read through both the links, and they’ll give you extra background.
If your concern is ensuring a killswitch type vpn setup, I do that but in a different and simple way.
I have a GLinet microrouter configured to join the vpn and active killswitch mode. This is 2 clicks in the menu. I connect it to my network via its wan port.
Everything I want behind the VPN gets connected to the microrouter lan port and job done.
Interesting! I’m new to this, this is really valuable! What made you choose this approach?
Its simple and I can easily put a laptop or phone or whatever behind the microrouter and have confidence its only using the vpn.
When I travel I take a second microrouter with me to connect to the hotel wifi. All my devices are set to use the microrouter wifi so they never touch the hotel network, only the vpn. Easy, private, and avoids any filtering the hotek is doing.
Cool! And you can easily control the mini router from your devices so that it connects to the hotel WiFi or whatever network you want?
Yes it has a web ui tp connect to wifi. For cable you just plug it in.
sudo ufw default deny outgoing
I’m guessing this would block the VPN packets themselves as well.
It does, but later I have the rules to counteract those, for the VPN specifically: sudo ufw allow in on tun0 sudo ufw allow out on tun0
So that would open that up again, or am I wrong?
That allows sending packets inside the VPN tunnel, but the outer envelope packets still need to be able to reach the VPN server.
I see, but then how would I disable everything else? Should I not use the default rules?
Add an allow rule for the VPN traffic on wlan0 to your VPN server.
Hmm, but wouldn’t that allow applications to communicate on wlan0 without using the vpn?
Thanks for your help and excuse my ignorance.
Only if they were a VPN app talking to the VPN server.
wg-quick takes a different approach, using an ip rule to send all traffic (except its own) to a different routing table with only the wireguard interface. I topped it up with iptables rules to block everything except DNS and the wireguard udp port on the main interface. I also disabled ipv6 on the main interface, to avoid any non-RFC1918 addresses appearing in the (in my case) container at all.
