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.
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?
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
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:
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?
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
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.