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 destinationYou 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 -nvNow, 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_forwardCheck 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.confThe 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-persistentBut wait. It looks like it’s still there. After reboot, you are still able to run:
/etc/init.d/iptables-persistent saveHere’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-persistentWhy 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.
