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.
Linux
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
Thanks! Unfortunately my VPN is OpenVPN and doesn't support Wireguard yet :(
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.
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 udp
You 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!
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.
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 to connect to wifi. For cable you just plug it in.
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.
edit: you can also do ip rule matching based on uid, such that you could force all non-root users to use your custom route table.