Enabling Killswitch on dietpi-VPN completely kills the internet

Details:

  • Date | Sat Feb 4 10:11:56 CST 2023
  • DietPi version | v8.13.2 (MichaIng/master)
  • Image creator | DietPi Core Team
  • Pre-image | from scratch
  • Hardware | RPi 4 Model B (aarch64) (ID=4)
  • Kernel version | Linux DietPi 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023 aarch64 GNU/Linux
  • Distro | bullseye (ID=6,RASPBIAN=0)
  • Command | curl -sSfLO https://www.privateinternetaccess.com/openvpn/openvpn-strong.zip
  • Exit code | 6
  • Software title | DietPi-VPN

Steps to reproduce:

  1. Setup dietpi-vpn with PIA, enable auto start and killswitch

Expected behaviour:

  • internet should still work

Actual behaviour:

  • internet completely dies

Extra details:

I have 2 Dietpi’s in myhouse. My “main” one runs jackett, radarr, sonarr, deluge, sabnzbd, pihole, samba, unbound
My second one runs pihole and unbound

Main: hostname dietpi 192.168.86.100
Second: hostname dietpi2 192.168.86.200

After reading other posts about dietpi-vpn I set my piholes both to use cloudflare DNS instead of unbound for upstream DNS.

I’ve had Dietpi-vpn setup on my “main” forever but the killswitch never worked, the entire internet just stopped but I never had a problem so I just let it be. After complete reinstalls of Bullseye I reconfigured everything the way I like it. Then I got a DMCA notice and checked to see if the VPN was up, it was. I enabled the killswitch to check to see if it was fixed, and everything still is broken.

I went to my 2nd unit only running pihole and unbound and configured dietpi-vpn with the exact same settings and enabled the killswitch, and it still works without an issue. I feel like the VPN on my “main” isnt actually working even thought the WAN IP is listed as the VPN IP.

When the killswitch is enabled on the main I cannot even ping 8.8.8.8. When the killswitch is enabled on the secondary it pings fine.

Both units are configured in dietpi-config to use 1.1.1.1 and 1.0.0.1 for static DNS.

The “primary” is my DHCP server.

Please let me know what logs are relevant to seeing why the killswitch complete breaks my “main” but not the secondary.

Additional logs:

curl: (6) Could not resolve host: www.privateinternetaccess.com

Screenshot of the “Dietpi2” VPN config and being able to ping 8.8.8.8 with killswitch enabled


Output from “main” Dietpi after enabling killswitch and trying to ping 8.8.8.8

root@DietPi:~# dietpi-vpn
[  OK  ] DietPi-VPN | systemctl enable dietpi-vpn
[ INFO ] DietPi-VPN | Checking for required APT packages: iptables
[  OK  ] DietPi-VPN | chmod +x /var/lib/dietpi/dietpi-vpn/static_up.sh /var/lib/dietpi/dietpi-vpn/static_down.sh
[  OK  ] DietPi-VPN | umask 0077
[ INFO ] DietPi-VPN | Generating OVPN file, please wait...
[  OK  ] DietPi-VPN | cp -f /etc/openvpn/pia/us_east.ovpn /etc/openvpn/client.ovpn
[  OK  ] DietPi-VPN | Desired setting in /etc/openvpn/client.ovpn was already set: proto udp
[  OK  ] DietPi-VPN | sed -i /^[[:blank:]]*remote[[:blank:]]/s/[[:blank:]][0-9][0-9]*$/ 1197/ /etc/openvpn/client.ovpn
[  OK  ] DietPi-VPN | umask 0022
[  OK  ] DietPi-VPN | chmod 0600 /var/lib/dietpi/dietpi-vpn/settings_ovpn.conf /var/lib/dietpi/dietpi-vpn/settings_dietpi.conf /etc/openvpn/client.ovpn
[  OK  ] DietPi-VPN | chown root:root /var/lib/dietpi/dietpi-vpn/settings_ovpn.conf /var/lib/dietpi/dietpi-vpn/settings_dietpi.conf /etc/openvpn/client.ovpn
[  OK  ] DietPi-VPN | Setting in /etc/openvpn/client.ovpn adjusted: auth-user-pass /var/lib/dietpi/dietpi-vpn/settings_ovpn.conf
[  OK  ] DietPi-VPN | Added setting script-security 2 to /etc/openvpn/client.ovpn after line auth sha256
[  OK  ] DietPi-VPN | Added setting up /var/lib/dietpi/dietpi-vpn/static_up.sh to /etc/openvpn/client.ovpn after line script-security 2
[  OK  ] DietPi-VPN | Added setting down /var/lib/dietpi/dietpi-vpn/static_down.sh to /etc/openvpn/client.ovpn after line up /var/lib/dietpi/dietpi-vpn/static_up.sh
[  OK  ] DietPi-VPN | sed -i /^[[:blank:]]*route-up[[:blank:]]/d /etc/openvpn/client.ovpn
[  OK  ] DietPi-VPN | sed -i /^[[:blank:]]*route-pre-down[[:blank:]]/d /etc/openvpn/client.ovpn
[ INFO ] DietPi-VPN | Checking for required APT packages: openvpn
[  OK  ] DietPi-VPN | systemctl restart dietpi-vpn
[  OK  ] DietPi-VPN | Connection established: us_east.ovpn
root@DietPi:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

One more quick note that I have been using dietpi-vpn on my main Dietpi and the VPN Status in the banner has never once showed anything other than Sent = 0MiB | Received = 0MiB. However after 15 minutes of testing yesterday on Dietpi2 and the killswitch enabled, I saw the Received = 45MiB.

I am noticing the Dietpi (main) is showing 2 tunnel interfaces, while dietpi2 (working killswitch) shows 1. Not sure if that is relevant.

Dietpi

root@DietPi:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:8d:99:df brd ff:ff:ff:ff:ff:ff
    inet 192.168.86.100/24 brd 192.168.86.255 scope global eth0
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0
       valid_lft forever preferred_lft forever
4: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 10.1.110.68/24 scope global tun1
       valid_lft forever preferred_lft forever
root@DietPi:~#

Dietpi2

root@DietPi2:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default                           qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP grou                          p default qlen 1000
    link/ether b8:27:eb:33:62:a0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.86.200/24 brd 192.168.86.255 scope global eth0
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state                           UNKNOWN group default qlen 500
    link/none
    inet 10.9.19.12/24 scope global tun0
       valid_lft forever preferred_lft forever

did you maybe setup something like PiVPN server?

I did not. This was a fresh install. This is a screenshot of the uninstall screen in Dietpi-software

I notice Dietpi2 doesnt have OpenVPN installed. Maybe thats it.

Manually uninstalled Openvpn. Complete reset of Dietpi-vpn. Set it back up with killswitch enabled. Still unable to ping anything. Seems to be down to 1 tunnel though.

root@DietPi:~# dietpi-vpn
[  OK  ] DietPi-VPN | systemctl disable --now dietpi-vpn
[  OK  ] DietPi-VPN | rm -Rf /etc/openvpn/client.ovpn /var/lib/dietpi/dietpi-vpn /etc/openvpn/nordvpn /etc/openvpn/protonvpn /etc/openvpn/ipvanish /etc/openvpn/pia
[ INFO ] DietPi-VPN | APT purge for: openvpn, please wait...
[ INFO ] DietPi-VPN | None of the requested packages are currently installed. Aborting...
[  OK  ] DietPi-VPN | APT purge for: openvpn
root@DietPi:~# dietpi-vpn
[  OK  ] DietPi-VPN | mkdir -p /var/lib/dietpi/dietpi-vpn
[  OK  ] DietPi-VPN | curl -sSfLO https://www.privateinternetaccess.com/openvpn/openvpn-strong.zip
[  OK  ] DietPi-VPN | mkdir -p /etc/openvpn/pia
[  OK  ] DietPi-VPN | unzip -o openvpn-strong.zip -d /etc/openvpn/pia
[  OK  ] DietPi-VPN | rm openvpn-strong.zip
[ INFO ] DietPi-VPN | Populating VPN server list, please wait...
[  OK  ] DietPi-VPN | systemctl enable dietpi-vpn
[ INFO ] DietPi-VPN | Checking for required APT packages: iptables
[  OK  ] DietPi-VPN | chmod +x /var/lib/dietpi/dietpi-vpn/static_up.sh /var/lib/dietpi/dietpi-vpn/static_down.sh
[  OK  ] DietPi-VPN | umask 0077
[ INFO ] DietPi-VPN | Generating OVPN file, please wait...
[  OK  ] DietPi-VPN | cp -f /etc/openvpn/pia/us_east.ovpn /etc/openvpn/client.ovpn
[  OK  ] DietPi-VPN | Desired setting in /etc/openvpn/client.ovpn was already set: proto udp
[  OK  ] DietPi-VPN | sed -i /^[[:blank:]]*remote[[:blank:]]/s/[[:blank:]][0-9][0-9]*$/ 1197/ /etc/openvpn/client.ovpn
[  OK  ] DietPi-VPN | umask 0022
[  OK  ] DietPi-VPN | chmod 0600 /var/lib/dietpi/dietpi-vpn/settings_ovpn.conf /var/lib/dietpi/dietpi-vpn/settings_dietpi.conf /etc/openvpn/client.ovpn
[  OK  ] DietPi-VPN | chown root:root /var/lib/dietpi/dietpi-vpn/settings_ovpn.conf /var/lib/dietpi/dietpi-vpn/settings_dietpi.conf /etc/openvpn/client.ovpn
[  OK  ] DietPi-VPN | Setting in /etc/openvpn/client.ovpn adjusted: auth-user-pass /var/lib/dietpi/dietpi-vpn/settings_ovpn.conf
[  OK  ] DietPi-VPN | Added setting script-security 2 to /etc/openvpn/client.ovpn after line auth sha256
[  OK  ] DietPi-VPN | Added setting up /var/lib/dietpi/dietpi-vpn/static_up.sh to /etc/openvpn/client.ovpn after line script-security 2
[  OK  ] DietPi-VPN | Added setting down /var/lib/dietpi/dietpi-vpn/static_down.sh to /etc/openvpn/client.ovpn after line up /var/lib/dietpi/dietpi-vpn/static_up.sh
[  OK  ] DietPi-VPN | sed -i /^[[:blank:]]*route-up[[:blank:]]/d /etc/openvpn/client.ovpn
[  OK  ] DietPi-VPN | sed -i /^[[:blank:]]*route-pre-down[[:blank:]]/d /etc/openvpn/client.ovpn
[ INFO ] DietPi-VPN | Checking for required APT packages: openvpn
[ INFO ] DietPi-VPN | APT update, please wait...
Hit:1 https://download.mono-project.com/repo/debian buster InRelease
Hit:2 https://deb.debian.org/debian bullseye InRelease
Hit:3 https://deb.debian.org/debian bullseye-updates InRelease
Hit:4 https://deb.debian.org/debian-security bullseye-security InRelease
Hit:5 https://deb.debian.org/debian bullseye-backports InRelease
Hit:6 https://apt.sonarr.tv/debian buster InRelease
Get:7 https://archive.raspberrypi.org/debian bullseye InRelease [23.6 kB]
Get:8 https://archive.raspberrypi.org/debian bullseye/main arm64 Packages [302 kB]
Fetched 326 kB in 4s (78.2 kB/s)
Reading package lists...
[  OK  ] DietPi-VPN | APT update
[ INFO ] DietPi-VPN | APT install for: openvpn, please wait...
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  liblzo2-2 libpkcs11-helper1
Suggested packages:
  resolvconf openvpn-systemd-resolved
Recommended packages:
  easy-rsa
The following NEW packages will be installed:
  liblzo2-2 libpkcs11-helper1 openvpn
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 664 kB of archives.
After this operation, 1939 kB of additional disk space will be used.
Get:1 https://deb.debian.org/debian bullseye/main arm64 liblzo2-2 arm64 2.10-2 [51.8 kB]
Get:2 https://deb.debian.org/debian bullseye/main arm64 libpkcs11-helper1 arm64 1.27-1 [44.9 kB]
Get:3 https://deb.debian.org/debian bullseye/main arm64 openvpn arm64 2.5.1-3 [568 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 664 kB in 1s (1301 kB/s)
                                Selecting previously unselected package liblzo2-2:arm64.
(Reading database ... 34715 files and directories currently installed.)
Preparing to unpack .../liblzo2-2_2.10-2_arm64.deb ...
Unpacking liblzo2-2:arm64 (2.10-2) ...
Selecting previously unselected package libpkcs11-helper1:arm64.
Preparing to unpack .../libpkcs11-helper1_1.27-1_arm64.deb ...
Unpacking libpkcs11-helper1:arm64 (1.27-1) ...
Selecting previously unselected package openvpn.
Preparing to unpack .../openvpn_2.5.1-3_arm64.deb ...
Unpacking openvpn (2.5.1-3) ...
Setting up liblzo2-2:arm64 (2.10-2) ...
Setting up libpkcs11-helper1:arm64 (1.27-1) ...
Setting up openvpn (2.5.1-3) ...
Created symlink /etc/systemd/system/multi-user.target.wants/openvpn.service → /lib/systemd/system/openvpn.service.
Processing triggers for libc-bin (2.31-13+rpt2+rpi1+deb11u5) ...
[  OK  ] DietPi-VPN | APT install for: openvpn
[  OK  ] DietPi-VPN | systemctl restart dietpi-vpn
[  OK  ] DietPi-VPN | Connection established: us_east.ovpn
root@DietPi:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1001ms

root@DietPi:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:8d:99:df brd ff:ff:ff:ff:ff:ff
    inet 192.168.86.100/24 brd 192.168.86.255 scope global eth0
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 10.21.110.19/24 scope global tun0
       valid_lft forever preferred_lft forever
root@DietPi:~# ip r
0.0.0.0/1 via 10.21.110.1 dev tun0
default via 192.168.86.1 dev eth0 onlink
10.21.110.0/24 dev tun0 proto kernel scope link src 10.21.110.19
128.0.0.0/1 via 10.21.110.1 dev tun0
191.96.185.210 via 192.168.86.1 dev eth0
192.168.86.0/24 dev eth0 proto kernel scope link src 192.168.86.100
root@DietPi:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:8d:99:df brd ff:ff:ff:ff:ff:ff
    inet 192.168.86.100/24 brd 192.168.86.255 scope global eth0
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 10.21.110.19/24 scope global tun0
       valid_lft forever preferred_lft forever
root@DietPi:~#

out of curiosity, both systems using same VPN provider?

Yes. PIA. Same username and pass. I had them configured for different servers initially but both are now on us_east. I’m taking a look at iptables --list and on Dietpi it takes minutes to slow. On Dietpi2 it is very quick.

While the killswitch is on I have been unable to ping dietpi 192.68.86.100 from either my PC or dietpi 2. I added these rules into iptables and can ping dietpi locally now.

iptables -I INPUT -p all -s 192.168.86.0/24 -j ACCEPT
iptables -I OUTPUT -p all -d 192.168.86.0/24 -j ACCEPT

Output of iptables --list on dietpi2 (takes 2 seconds to load)

root@DietPi2:~# iptables --list
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     tcp  --  192.168.86.0/24      anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy DROP)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             192.168.86.0/24
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             192.168.0.0/16
ACCEPT     all  --  anywhere             172.16.0.0/12
ACCEPT     all  --  anywhere             10.0.0.0/8
ACCEPT     tcp  --  anywhere             102.165.16.108       tcp dpt:501
ACCEPT     tcp  --  anywhere             102.165.16.109       tcp dpt:501
ACCEPT     tcp  --  anywhere             191.96.185.93        tcp dpt:501

Output of iptables --list on dietpi (takes 2 minutes to load)

root@DietPi:~# iptables --list
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  192.168.86.0/24      anywhere
ACCEPT     tcp  --  192.168.86.0/24      anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             192.168.86.0/24
ACCEPT     tcp  --  anywhere             192.168.86.0/24
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             192.168.0.0/16
ACCEPT     all  --  anywhere             172.16.0.0/12
ACCEPT     all  --  anywhere             10.0.0.0/8
ACCEPT     udp  --  anywhere             191.96.185.218       udp dpt:1197
ACCEPT     udp  --  anywhere             191.96.185.227       udp dpt:1197
ACCEPT     udp  --  anywhere             191.96.185.248       udp dpt:1197

this is as expected and purpose of the killswitch. To block local network access (accept SSH), to ensure entire traffic is routed via VPN tunnel.

Turning off the killswitch setting, applying the settings and exiting diet-vpn still seems to have iptables active, and still cannot get outbound.

 root@DietPi:~# dietpi-vpn
[  OK  ] DietPi-VPN | rm /var/lib/dietpi/dietpi-vpn/killswitch.rules
[  OK  ] DietPi-VPN | chmod +x /var/lib/dietpi/dietpi-vpn/static_up.sh /var/lib/dietpi/dietpi-vpn/static_down.sh
[  OK  ] DietPi-VPN | umask 0077
[ INFO ] DietPi-VPN | Generating OVPN file, please wait...
[  OK  ] DietPi-VPN | cp -f /etc/openvpn/pia/us_east.ovpn /etc/openvpn/client.ovpn
[  OK  ] DietPi-VPN | Desired setting in /etc/openvpn/client.ovpn was already set: proto udp
[  OK  ] DietPi-VPN | sed -i /^[[:blank:]]*remote[[:blank:]]/s/[[:blank:]][0-9][0-9]*$/ 1197/ /etc/openvpn/client.ovpn
[  OK  ] DietPi-VPN | umask 0022
[  OK  ] DietPi-VPN | chmod 0600 /var/lib/dietpi/dietpi-vpn/settings_ovpn.conf /var/lib/dietpi/dietpi-vpn/settings_dietpi.conf /etc/openvpn/client.ovpn
[  OK  ] DietPi-VPN | chown root:root /var/lib/dietpi/dietpi-vpn/settings_ovpn.conf /var/lib/dietpi/dietpi-vpn/settings_dietpi.conf /etc/openvpn/client.ovpn
[  OK  ] DietPi-VPN | Setting in /etc/openvpn/client.ovpn adjusted: auth-user-pass /var/lib/dietpi/dietpi-vpn/settings_ovpn.conf
[  OK  ] DietPi-VPN | Added setting script-security 2 to /etc/openvpn/client.ovpn after line auth sha256
[  OK  ] DietPi-VPN | Added setting up /var/lib/dietpi/dietpi-vpn/static_up.sh to /etc/openvpn/client.ovpn after line script-security 2
[  OK  ] DietPi-VPN | Added setting down /var/lib/dietpi/dietpi-vpn/static_down.sh to /etc/openvpn/client.ovpn after line up /var/lib/dietpi/dietpi-vpn/static_up.sh
[  OK  ] DietPi-VPN | sed -i /^[[:blank:]]*route-up[[:blank:]]/d /etc/openvpn/client.ovpn
[  OK  ] DietPi-VPN | sed -i /^[[:blank:]]*route-pre-down[[:blank:]]/d /etc/openvpn/client.ovpn
[ INFO ] DietPi-VPN | Checking for required APT packages: openvpn
[  OK  ] DietPi-VPN | systemctl restart dietpi-vpn
[FAILED] DietPi-VPN | Connection failed/timeout: us_east.ovpn
[  OK  ] DietPi-VPN | systemctl stop dietpi-vpn
^C
root@DietPi:~# ^C
root@DietPi:~# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7158ms

root@DietPi:~# iptables --list
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  192.168.86.0/24      anywhere
ACCEPT     tcp  --  192.168.86.0/24      anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             192.168.86.0/24
ACCEPT     tcp  --  anywhere             192.168.86.0/24
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             192.168.0.0/16
ACCEPT     all  --  anywhere             172.16.0.0/12
ACCEPT     all  --  anywhere             10.0.0.0/8
ACCEPT     udp  --  anywhere             191.96.185.218       udp dpt:1197
ACCEPT     udp  --  anywhere             191.96.185.227       udp dpt:1197
ACCEPT     udp  --  anywhere             191.96.185.248       udp dpt:1197
root@DietPi:~#

This is usually fixed by a reboot in my testing.

@trendy may I ask for your assistance

What is the output of

ip -4 addr ; ip -4 ro li tab all ; ip -4 ru; \
iptables-save -c ;\
ls -l  /etc/resolv* ; head -n -0 /etc/resolv* /etc/resolvconf/resolv.conf.d/*

You can take the snapshot with vpn and killswitch up.

On Dietpi with VPN and killswitch on

root@DietPi:~# ip -4 addr ; ip -4 ro li tab all ; ip -4 ru; \
iptables-save -c ;\
ls -l  /etc/resolv* ; head -n -0 /etc/resolv* /etc/resolvconf/resolv.conf.d/*
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet 192.168.86.100/24 brd 192.168.86.255 scope global eth0
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    inet 10.14.110.15/24 scope global tun0
       valid_lft forever preferred_lft forever
0.0.0.0/1 via 10.14.110.1 dev tun0
default via 192.168.86.1 dev eth0 onlink
10.14.110.0/24 dev tun0 proto kernel scope link src 10.14.110.15
102.165.16.173 via 192.168.86.1 dev eth0
128.0.0.0/1 via 10.14.110.1 dev tun0
192.168.86.0/24 dev eth0 proto kernel scope link src 192.168.86.100
local 10.14.110.15 dev tun0 table local proto kernel scope host src 10.14.110.15
broadcast 10.14.110.255 dev tun0 table local proto kernel scope link src 10.14.110.15
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
local 192.168.86.100 dev eth0 table local proto kernel scope host src 192.168.86.100
broadcast 192.168.86.255 dev eth0 table local proto kernel scope link src 192.168.86.100
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default
# Generated by iptables-save v1.8.7 on Sat Feb  4 16:01:34 2023
*filter
:INPUT DROP [39:7909]
:FORWARD DROP [0:0]
:OUTPUT DROP [1:93]
[13:3725] -A INPUT -i lo -j ACCEPT
[64:13318] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
[13:3725] -A OUTPUT -o lo -j ACCEPT
[28:4407] -A OUTPUT -o tun0 -j ACCEPT
[41:24952] -A OUTPUT -d 192.168.0.0/16 -j ACCEPT
[0:0] -A OUTPUT -d 172.16.0.0/12 -j ACCEPT
[0:0] -A OUTPUT -d 10.0.0.0/8 -j ACCEPT
[51:12226] -A OUTPUT -d 102.165.16.173/32 -p udp -m udp --dport 1197 -j ACCEPT
[0:0] -A OUTPUT -d 191.96.185.14/32 -p udp -m udp --dport 1197 -j ACCEPT
[0:0] -A OUTPUT -d 191.96.185.39/32 -p udp -m udp --dport 1197 -j ACCEPT
COMMIT
# Completed on Sat Feb  4 16:01:34 2023
-rw-r--r-- 1 root root   38 Feb  4 10:12 /etc/resolv.conf

/etc/resolvconf:
total 4
drwxr-xr-x 2 root root 4096 Jan 31 22:12 update.d
==> /etc/resolv.conf <==
nameserver 1.1.1.1
nameserver 1.0.0.1

==> /etc/resolvconf <==
head: error reading '/etc/resolvconf': Is a directory
head: cannot open '/etc/resolvconf/resolv.conf.d/*' for reading: No such file or directory
root@DietPi:~#

On Dietpi2 with VPN and killswitch

root@DietPi2:~# ip -4 addr ; ip -4 ro li tab all ; ip -4 ru; \
iptables-save -c ;\
ls -l  /etc/resolv* ; head -n -0 /etc/resolv* /etc/resolvconf/resolv.conf.d/*
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.86.200/24 brd 192.168.86.255 scope global eth0
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    inet 10.9.19.12/24 scope global tun0
       valid_lft forever preferred_lft forever
0.0.0.0/1 via 10.9.19.1 dev tun0
default via 192.168.86.1 dev eth0 onlink
10.9.19.0/24 dev tun0 proto kernel scope link src 10.9.19.12
102.165.16.108 via 192.168.86.1 dev eth0
128.0.0.0/1 via 10.9.19.1 dev tun0
192.168.86.0/24 dev eth0 proto kernel scope link src 192.168.86.200
local 10.9.19.12 dev tun0 table local proto kernel scope host src 10.9.19.12
broadcast 10.9.19.255 dev tun0 table local proto kernel scope link src 10.9.19.12
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
local 192.168.86.200 dev eth0 table local proto kernel scope host src 192.168.86.200
broadcast 192.168.86.255 dev eth0 table local proto kernel scope link src 192.168.86.200
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default
# Generated by iptables-save v1.8.7 on Sat Feb  4 16:02:34 2023
*filter
:INPUT DROP [20649:2496233]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
[4988:496575] -A INPUT -s 192.168.86.0/24 -p tcp -j ACCEPT
[14152:1121335] -A INPUT -i lo -j ACCEPT
[18765:3479066] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[2:104] -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
[4210:2987822] -A OUTPUT -d 192.168.86.0/24 -p tcp -j ACCEPT
[14152:1121335] -A OUTPUT -o lo -j ACCEPT
[5537:1478722] -A OUTPUT -o tun0 -j ACCEPT
[1648:314812] -A OUTPUT -d 192.168.0.0/16 -j ACCEPT
[0:0] -A OUTPUT -d 172.16.0.0/12 -j ACCEPT
[0:0] -A OUTPUT -d 10.0.0.0/8 -j ACCEPT
[15954:2633019] -A OUTPUT -d 102.165.16.108/32 -p tcp -m tcp --dport 501 -j ACCEPT
[0:0] -A OUTPUT -d 102.165.16.109/32 -p tcp -m tcp --dport 501 -j ACCEPT
[0:0] -A OUTPUT -d 191.96.185.93/32 -p tcp -m tcp --dport 501 -j ACCEPT
COMMIT
# Completed on Sat Feb  4 16:02:34 2023
-rw-r--r-- 1 root root   38 Feb  3 22:56 /etc/resolv.conf

/etc/resolvconf:
total 4
drwxr-xr-x 2 root root 4096 Jan 29 14:57 update.d
==> /etc/resolv.conf <==
nameserver 1.1.1.1
nameserver 1.0.0.1

==> /etc/resolvconf <==
head: error reading '/etc/resolvconf': Is a directory
head: cannot open '/etc/resolvconf/resolv.conf.d/*' for reading: No such file or directory

So interesting enough I am suddenly able to ping out. I made no changes except reboot from my post an hour ago. I am going to reboot again to see if the settings retain on reboot. I also noticed on Dietpi the Received = 1Mib which never happens.

update Upon reboot the settings have retained and I can get out again.

Yeah, I was checking the configs and I could not find anything suspicious.
Just one thing

-A INPUT -s 192.168.86.0/24 -p tcp -j ACCEPT
-A OUTPUT -d 192.168.86.0/24 -p tcp -j ACCEPT

you may want to remove these two, as the private address space is already allowed.

I had only added those so local devices can access the services Dietpi offers. Seeing as those rules were not persistent, and my local devices cannot access the services such as: pihole, smb, nfs, radarr, sonarr, sabnzd, deluge etc etc. Should I give up on having this device use the killswitch, or should I start manually adding iptables rules to allow those services to be accessible?

Main aim of our killswitch is to block local network access. Adding these lines will make the killswitch useless. Basically you could have it disabled or you go to allow each individual service.

I think part of my confusion here is PIA offering their client with split tunneling and a killswitch to block everything if the VPN goes down. Obviously this is not their client, and my assumption was that the dietpi-vpn killswitch would act in the same fashion. I am not sure if I can get their client to run they way I want it in a CLI only environment but I am willing to try. Short of that I suppose I could open individual ports through saving the iptables list and running them when the VPN comes up.