Dietpi_vpn not working if killswitch enabled for custom server

alleyu2 · 20 January 2023 10:44

Creating a bug report/issue

Required Information

DietPi version | DietPi v8.13.2
Distro version | bullseye 1
Kernel version | Linux DietPi-Pi4 5.15.84-v7l+ #1613 SMP Thu Jan 5 12:01:26 GMT 2023 armv7l GNU/Linux
SBC model | RPi 4 Model B (armv7l)
Power supply used | 5V 1A RAVpower
SD card used | SSD

Additional Information (if applicable)

Software title | dietpi-vpn
Was the software title installed freshly or updated/migrated? Tried this feature for the first time
Can this issue be replicated on a fresh installation of DietPi? Not tried
← If you sent a “dietpi-bugreport”, please paste the ID here →
Bug report ID | N/A

Steps to reproduce

Execute dietpi-vpn
Select vpn provide “Custom”
Select the vpn config file
Update username and password
Select Apply
VPN connects. State “connected” , WANIP allocated as per VPN provider.
Disconnect
Select Killswitch “On”
Select “Apply”
WAN IP “curl: (28) Resolving timed out after 3000 milliseconds” and State: Connected
No internet connection

Expected behaviour

Should be able to access internet when killwitch is “On” and vpn server is connected

Actual behaviour

Not able to access internet when killwitch is “On” and vpn server is connected

Joulinar · 20 January 2023 11:58

within the custom VPN config, do you specify a DNS server to be used?

alleyu2 · 20 January 2023 12:19

I guess no. This is my config

client
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
verb 3
remote-cert-tls server
ping 10
ping-restart 60
sndbuf 524288
rcvbuf 524288
cipher AES-256-CBC
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA
proto udp
auth-user-pass /var/lib/dietpi/dietpi-vpn/settings_ovpn.conf
ca /etc/openvpn/mullvad_ca.crt
tun-ipv6
script-security 2
up /var/lib/dietpi/dietpi-vpn/static_up.sh
down /var/lib/dietpi/dietpi-vpn/static_down.sh
fast-io
remote-random
remote x.x.x.x 1300 # hk-hkg-ovpn-101
remote x.x.x.x 1300 # hk-hkg-ovpn-202
remote x.x.x.x 1300 # hk-hkg-ovpn-201
remote x.x.x.x 1300 # hk-hkg-ovpn-102

alleyu2 · 20 January 2023 15:52

Is there a way to add dns in the config?

Joulinar · 20 January 2023 21:01

I’m not an OpenVPN expert but probably DNS server is assigned by the VPN server directly. Let’s do some testing.

First, install dnsutils package. We can use it to perform some DNS queries.

apt install dnsutils -y

Once installed, you can use following to check DNS server used. Run it with / without Killswitch activated

dig dietpi.com

On the bottom of the output, you will see somthing like this

;; Query time: 30 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Fri Jan 20 21:59:56 CET 2023
;; MSG SIZE  rcvd: 71

Within this example DNS SERVER: 9.9.9.9 is used.

alleyu2 · 21 January 2023 02:14

I got this response

; <<>> DiG 9.16.33-Raspbian <<>> dietpi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33452
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 202a76600d58c79101dcdc4763cb4a36e57cb4d4e422c019 (good)
;; QUESTION SECTION:
;dietpi.com.                    IN      A

;; ANSWER SECTION:
dietpi.com.             182     IN      A       104.21.28.141
dietpi.com.             182     IN      A       172.67.170.219

;; Query time: 100 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sat Jan 21 07:43:11 IST 2023
;; MSG SIZE  rcvd: 99

Joulinar · 21 January 2023 09:03

this is with active Killswitch? Because DNS resolutions is working in this case.

alleyu2 · 21 January 2023 09:07

Active kill switch is off. I have not internet connectivity with active kill switch

Joulinar · 21 January 2023 09:19

that’s exactly I like to test. If it is DNS resolution issue or not. Is ping 1.1.1.1 or ping 9.9.9.9 working with killswitch activated?

alleyu2 · 21 January 2023 10:09

With kill switch activated I get this


; <<>> DiG 9.16.33-Raspbian <<>> dietpi.com
;; global options: +cmd
;; connection timed out; no servers could be reached```

Joulinar · 21 January 2023 10:27

Did you tried to ping anything like 1.1.1.1, 8.8.8.8 or 9.9.9.9 on the internet?

Can you share following once Killswitch is active.

ip a; ip r

alleyu2 · 21 January 2023 10:41

ip a; ip r
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:00:42:67 brd ff:ff:ff:ff:ff:ff
    inet 192.168.31.150/24 brd 192.168.31.255 scope global eth0
       valid_lft forever preferred_lft forever
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.6.0.1/24 scope global wg0
       valid_lft forever preferred_lft forever
5: br-6fcc2b3163b3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:f7:10:26:a1 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-6fcc2b3163b3
       valid_lft forever preferred_lft forever
6: br-9e700094cf5e: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:ea:81:9c:7e brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.1/16 brd 172.19.255.255 scope global br-9e700094cf5e
       valid_lft forever preferred_lft forever
7: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:27:50:d0:39 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
11: veth9994eb2@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether fe:85:22:a0:f7:60 brd ff:ff:ff:ff:ff:ff link-netnsid 0
14: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 10.14.0.6/16 scope global tun0
       valid_lft forever preferred_lft forever
0.0.0.0/1 via 10.14.0.1 dev tun0
default via 192.168.31.1 dev eth0 onlink
10.6.0.0/24 dev wg0 proto kernel scope link src 10.6.0.1
10.14.0.0/16 dev tun0 proto kernel scope link src 10.14.0.6
Xxxxxx via 192.168.31.1 dev eth0
128.0.0.0/1 via 10.14.0.1 dev tun0
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-6fcc2b3163b3 proto kernel scope link src 172.18.0.1 linkdown
172.19.0.0/16 dev br-9e700094cf5e proto kernel scope link src 172.19.0.1 linkdown
192.168.31.0/24 dev eth0 proto kernel scope link src 192.168.31.150

Joulinar · 21 January 2023 14:13

It seems, still the local network gateway address is used and not the VPN tunnel gateway. And activating the killswitch is blocking local network access completely, leading to a failed internet connection, because VPN is not used.

If the killswitch of OFF, are you sure the VPN connection is working? Which IP does following return? You privat external IP address or the global VPN IP address?

G_GET_WAN_IP

@trendy maybe you can have a look as well.

alleyu2 · 21 January 2023 14:15

I am getting VPN global IP when using VPN without kill switch. I have check also via whatismyip as well.

trendy · 21 January 2023 17:30

I don’t see anything wrong. What is the output of iptables-save -c with the killswitch on?
Also @Joulinar asked you to run the dig dietpi.com with both killswitch off and on but there is only one result.

alleyu2 · 21 January 2023 17:38

I have shared both dig results. You will find it in the post above. Following is the output of iptables command with kill switch

iptables-save -c                                   # Generated by iptables-save v1.8.7 on Sat Jan 21 23:10:13 2023
*mangle
:PREROUTING ACCEPT [16484348:2317599220]
:INPUT ACCEPT [16482717:2314180987]
:FORWARD ACCEPT [1631:3418233]
:OUTPUT ACCEPT [32882795:40876293868]
:POSTROUTING ACCEPT [32885721:40880046095]
COMMIT
# Completed on Sat Jan 21 23:10:13 2023
# Generated by iptables-save v1.8.7 on Sat Jan 21 23:10:13 2023
*filter
:INPUT DROP [111:46092]
:FORWARD DROP [0:0]
:OUTPUT DROP [1553:177990]
[704:429170] -A INPUT -i lo -j ACCEPT
[1070:508042] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
[704:429170] -A OUTPUT -o lo -j ACCEPT
[1546:95389] -A OUTPUT -o tun0 -j ACCEPT
[323:39618] -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
[0:0] -A OUTPUT -d 103.125.233.48/32 -p udp -m udp --dport 1300 -j ACCEPT
COMMIT
# Completed on Sat Jan 21 23:10:13 2023
# Generated by iptables-save v1.8.7 on Sat Jan 21 23:10:13 2023
*nat
:PREROUTING ACCEPT [156801:9567946]
:INPUT ACCEPT [156726:9562717]
:OUTPUT ACCEPT [249448:14922727]
:POSTROUTING ACCEPT [249452:14922967]
:DOCKER - [0:0]
[155693:9382100] -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
[8109:486540] -A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
[0:0] -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
[0:0] -A POSTROUTING -s 172.19.0.0/16 ! -o br-9e700094cf5e -j MASQUERADE
[0:0] -A POSTROUTING -s 172.18.0.0/16 ! -o br-6fcc2b3163b3 -j MASQUERADE
[0:0] -A POSTROUTING -s 10.6.0.0/24 -o eth0 -m comment --comment wireguard-nat-rule -j MASQUERADE
[0:0] -A POSTROUTING -s 172.17.0.2/32 -d 172.17.0.2/32 -p tcp -m tcp --dport 9000 -j MASQUERADE
[0:0] -A DOCKER -i docker0 -j RETURN
[0:0] -A DOCKER -i br-9e700094cf5e -j RETURN
[0:0] -A DOCKER -i br-6fcc2b3163b3 -j RETURN
[4:240] -A DOCKER ! -i docker0 -p tcp -m tcp --dport 9002 -j DNAT --to-destination 172.17.0.2:9000
COMMIT
# Completed on Sat Jan 21 23:10:13 2023

trendy · 21 January 2023 18:01

Right, it was a different post and I missed that.
iptables also look fine. It looks like mullvad is blocking the public dns.
What is the output of cat /etc/resolv.conf with vpn on and off?

Joulinar · 21 January 2023 20:16

can you check if you can ping one of these IP’s while the Killswitch is active?

alleyu2 · 22 January 2023 02:56

VPN and without kill switch

 cat /etc/resolv.conf                                            # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.

nameserver 1.1.1.1
nameserver 1.0.0.1

With Kill switch

cat /etc/resolv.conf                                            # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.

nameserver 1.1.1.1
nameserver 1.0.0.1

alleyu2 · 22 January 2023 02:57

There is no response when I ping 1.1.1.1