Understanding Why UFW Ignores VPN Traffic
The Uncomplicated Firewall (UFW) in Ubuntu and related distributions relies heavily on interface names to determine which packets to filter. By default, UFW rules are applied to physical interfaces such aseth0, wlan0, or enp3s0. When you establish a connection to a Virtual Private Network, the operating system creates a new virtual network interface, typically named tun0, tun1, or similar depending on the VPN client used.
Traffic flowing through this new interface does not automatically match the existing rules bound to your primary internet connection. If your rule was written as "Allow SSH from any on eth0", it will simply ignore packets arriving on tun0. Furthermore, some VPN clients modify the default route, sending all traffic through the tunnel. If UFW is not explicitly configured to inspect these virtual interfaces, your firewall appears to be "broken" because it is effectively blind to the traffic passing through the VPN.
To resolve this, you must understand that UFW operates at the netfilter layer but uses simple abstraction rules. You cannot simply add a generic rule without specifying the interface or relying on the default policy for new interfaces. The most common mistake users make is assuming that enabling UFW globally will protect all subsequent interfaces created by software. It does not; it only protects interfaces present and recognized at the time of rule creation or those explicitly added later.
Diagnosing Current Rule Application
Before modifying configurations, verify exactly what UFW is currently tracking. Use the following command to list all active rules with verbose output:sudo ufw status verbose
Look for the line that says "Default:" and check the incoming and outgoing policies. More importantly, look at the individual rules. If you see rules specific to an interface like on eth0, note that down. If you do not see any rules mentioning tun0, tap0, or your VPN provider's specific interface name, then that confirms the diagnosis.
You can also check if the VPN interface exists and its state using standard Linux networking tools:
ip addr show | grep tun
If the interface is up, confirm that UFW is actually monitoring it. Sometimes, the kernel module required for UFW might need to be reloaded if the interface appeared after UFW started. However, in most modern Ubuntu versions, UFW dynamically detects new interfaces if the default policies are set correctly.
Configuring UFW for VPN Interfaces
There are two primary approaches to fixing this issue. The first is adding explicit rules for the VPN interface. The second is adjusting the default policies to ensure that even unlisted interfaces are handled securely. Method 1: Explicit Interface Rules If you want to allow specific services over the VPN, you must append the interface name to your UFW commands. For example, to allow SSH over a TUN interface, use:sudo ufw allow in on tun0 to any port 22 proto tcp
Replace tun0 with the actual interface name shown in your ip addr output. Be cautious with wildcard interface names. Do not use tun* unless you are certain about the naming convention, as this could inadvertently open ports on multiple tunnel interfaces if they are created sequentially.
Method 2: Adjusting Default Policies
A more robust solution for many users is to ensure that the default incoming policy is deny. If your default incoming policy is set to deny, any traffic on a new interface like tun0 that does not have an explicit allow rule will be dropped by default. This is often safer than trying to manage every possible VPN interface manually.
Check your current default policy:
sudo ufw status verbose
If the default incoming is allow, consider changing it to deny for higher security, though this requires careful setup of outgoing and loopback rules to avoid locking yourself out. A balanced approach is to keep the default incoming as deny but ensure you have rules for your local network and loopback interface.
Ensuring Persistence After Reboot
Rules added via the command line persist across reboots in UFW. However, if you are using a GUI tool or a script that modifies UFW, ensure it is saved correctly. Always enable UFW after making changes:sudo ufw enable
If UFW complains about conflicting iptables rules, you may need to flush old rules before enabling:
sudo ufw reset
sudo ufw enable
This process clears any stale states that might interfere with the new interface detection.
For further reading on managing UFW in different environments, you might find these articles helpful:
Ubuntu 22.4.4 LTS: UFW Firewall Allows SSH but Prevents Connection to Another Server
Kubuntu UFW: Block Incoming, Allow Outgoing
Frequently Asked Questions
Does UFW automatically protect new interfaces?
No, UFW does not automatically create rules for new interfaces. It applies existing rules based on interface names. If a new interface like tun0 is created, it will only be protected if there is a matching rule or if the default policy catches it.
How do I find my VPN interface name?
You can find the interface name by running ip addr show in the terminal. Look for interfaces starting with tun, tap, or wg depending on your VPN client type.
Can I use a wildcard for VPN interfaces?
While you can technically use wildcards in some contexts, it is risky. It is better to identify the exact interface name and create a specific rule for it to avoid unintended security exposures.
Why is my VPN still leaking data despite UFW rules?
Data leaks often occur due to DNS requests or IPv6 traffic that bypasses the IPv4 firewall rules. Ensure your VPN client has a kill switch enabled and that UFW is configured to handle IPv6 if necessary.
Should I disable UFW when using a VPN?
No, you should not disable UFW. Disabling it removes a critical layer of defense. Instead, configure UFW to work alongside the VPN by adding appropriate rules for the tunnel interface.