I had an interesting interaction when using DietPi. I turned on the killswitch option in the VPN section and suddenly I couldn’t access the web interface for any installed package on the Raspberry Pi.
It looks like DietPi didn’t include scripts to automatically configure iptables
with installed packages. Yes, the routes were added for the killswitch but that was it. I’m surprised this is missing here. Everything else has been easy enough to setup up until this point. Although, this is either new or obscure enough to not really be a problem.
There are three main ways to “fix” this problem, configuring iptables
properly, disabling the firewall, or removing the iptables
package entirely. I’ll walk you through how I found out how I learned to fix the problem.
Table of Contents
Checking IPtables Status
Start with typing iptables -L
. What shows up?
root@raspi:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
You should see this type of output except it will be filled out. Review what your information is. Next up let’s see if iptables
is actually enabled.
Is IPtables Actually Enabled?
To see if it is actually enabled type:
sudo iptables -L -nv
Now, if you see this type of output, then your firewall is already disabled:
root@debian:~# sudo iptables -L -nv
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
To verify, type:
echo 0 > /proc/sys/net/ipv4/ip_forward
Check Subnet Mask
First, we checked if things were working and are enabled. Before we get into removing rules and removing packages, let’s verify the settings are correct.
Are the connectivity issues only with web interfaces or can you not connect to sections of your local network?
When you ping
and netcat
, it may appear as if there is a firewall issue. The issue is most likely a configuration problem with your network settings.
Check to see if your subnet mask is correct. It defaults to /8 in the GUI, which means it will only communicate with the gateway if the destination IP is outside of /8, instead of the typical /24 mask. If this is the case, you have a routing misconfiguration. The subnet is too wide.
Flushing All Chains
Flushing all chains means deleting all firewall rules. To do so, you can either use -F
or --flush
:
sudo iptables -F
sudo iptables-save > /etc/iptables.conf
The second line is to save the configuration. If you don’t save, your change will revert back after you reboot.
Uninstalling IPtables to Test
If you have made it this far, it’s time to test uninstalling iptables-persistent
. Type this command:
sudo apt remove --auto-remove iptables-persistent
But wait. It looks like it’s still there. After reboot, you are still able to run:
/etc/init.d/iptables-persistent save
Here’s the deal. Files in /etc
are config files and remain after you remove a package. This is useful if you ever need to reinstall anything. In order to get rid of these files, you must purge
the package. Type this command:
sudo apt remove --purge iptables-persistent
Why Does an IPtables Rule Disappear on Reboot?
What is iptables-persistent
? This has to do with why rules disappear on reboot. If you add a rule to iptables
to ban an IP and it works but doesn’t stick around after reboot, then note the following:
iptables-persistent
snapshots the rules on install. If you edit your rules, you would have to manually update the files in /etc/iptables/
.
Final Thoughts
I was able to fix my problem, but I didn’t like the way it behaved. So I disabled the VPN killswitch and reverted the changed iptables
config files. Autoconnect seems to fit the bill here.