Date and Time incorrect Vero 4K +

MarchHare · 18 November 2021 10:40

I will have to install dig because I don’t have that, I tried it yesterday.

The following NEW packages will be installed:
  dnsutils libirs161
The following packages will be upgraded:
  bind9-host libbind9-161 libdns1104 libisc1100 libisccc161 libisccfg163
  liblwres161

I restarted the VPN through SSH with sudo systemctl restart openvpn then the leak went away.

I don’t know if this is possible but could a script check if there are 2 DNS servers? Since there should always be one when the VPN is connected this could be a reason to restart too.

Tom_Doyle · 18 November 2021 10:52

Hi,

All I can suggest at this point is a slight modification of the script
/usr/local/sbin/watchdog.sh:

#!/bin/bash
GW=$(ip route show 0.0.0.0/1 dev tun0 | cut -d\  -f3)
ping -c1 $GW > /dev/null
if [ $? -eq 0 ]
  then
    echo ok
    exit 0
  else
    systemctl stop openvpn
    sleep 5
    systemctl start openvpn
fi

I’ll have to have a think about this.

Thanks Tom.

MarchHare · 18 November 2021 11:08

Tom_Doyle:

#!/bin/bash
GW=$(ip route show 0.0.0.0/1 dev tun0 | cut -d\  -f3)
ping -c1 $GW > /dev/null
if [ $? -eq 0 ]
  then
    echo ok
    exit 0
  else
    systemctl stop openvpn
    sleep 5
    systemctl start openvpn
fi

This will make it wait to reconnect for 5 minutes? Then it will be leaking too because the DNS will be able to send requests when the VPN is down since I have 1.1.1.1 in MyOSMC.

Ok, if you could think of something that would be great, this way the VPN is never reliable.
I think that a check would have to do the same thing as the DNS leak test Add-on does, if the DNS is from the same IP block it’s not leaking but if IPs from another block show up it’s leaking so it has to restart.

Tom_Doyle · 18 November 2021 11:25

Hi,

No, it will wait 5 seconds.

Thanks Tom.

@MarchHare

So I’ve not found anything that would cause a restart on dns leaks, but a google search has provided some additions to the conf file that should prevent dns leaks. Please try updating the last few lines of the conf file to:

script-security 2
dhcp-option DNS 10.0.0.243
dhcp-option DOMAIN-ROUTE .
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Thanks Tom.

MarchHare · 18 November 2021 12:36

I edited the ovpn config file and it looks like this at the bottom now

disable-occ
script-security 2
dhcp-option DNS 10.0.0.243
dhcp-option DOMAIN-ROUTE .
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Is this ok? should it be DOMAIN-ROUTE . ?
What does this do? Block all other routing except for PIA’s DNS when it’s connected? I’m trying to understand what the changes do.

Should I still edit the watchdog.sh to sleep for 5 seconds?

Tom_Doyle · 18 November 2021 13:26

Hi,

I’m hoping it forces all dns requests through PIA.

If the latest additons to the vpn conf file don’t work, please revert to:

disable-occ
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

And try watchdog.sh work around with the 5 second sleep.

Thanks Tom.

MarchHare · 19 November 2021 11:01

It started leaking again. When I check the DNS leak test it shows a server from Germany. The VPN didn’t restart so the leaks aren’t consistent. I’m checking the leaktest on kodi right now and it shows up but when I dig osmc.tv it doesn’t. But this means that it doesn’t have anything to do with the VPN shutting off, it leaks while it is still connected without disconnecting.
When I leave the DNS leak program open the DNS from germany sometimes shows up when it refreshes and sometimes disappears when it refreshes afterwards.

dig osmc.tv

; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> osmc.tv
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29661
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;osmc.tv.                       IN      A

;; ANSWER SECTION:
osmc.tv.                300     IN      A       77.68.92.173

;; Query time: 286 msec
;; SERVER: 10.0.0.243#53(10.0.0.243)
;; WHEN: Fri Nov 19 11:58:37 CET 2021
;; MSG SIZE  rcvd: 52

Tom_Doyle · 19 November 2021 11:30

HI,

If dig is showing the correct server, perhaps the kodi addon is wrong. Also one PIAs dns servers could be located in Germany?

Thanks Tom.

MarchHare · 19 November 2021 13:37

I used the dig command after the leak resolved because it only happens for a few minutes. The leak comes and goes. I’m sure it’s a leak because it’s 2 different data centers and 2 different IP blocks.
Since the OpenVPN connection asks to find a DNS server the 10.x.x.x range PIA says it should always be the same IP block.
The other Data center in Germany is also not owned or leased by PIA but is used for cloudflare, I don’t remember the exact IP because I did the IP lookup yesterday and didn’t do it today but it’s used for Cloudflare DNS.
So unfortunately it’s still leaking, and it isnt’ a constant leak either but comes and goes while the VPN is connected, so it goes around the VPN connection and requests through Eth0 instead of Tun0 on port 53 because through Tun0 all requests to other domains should be blocked and routed to 10.x.x.x…
I never had this problem before, it always reported 1 DNS on the same IP block.

Tom_Doyle · 19 November 2021 14:12

Hi,

I suspect it always leaked then, but PIA used public addresses; so it was less noticeable.

All I can suggest is removing the iptables rules allowing outbound dns requests via eth0 once the the VPN connection up. So once the connection is up issue:

sudo iptables -D OUTPUT -o eth0 -p udp -m udp --dport 53 -j ACCEPT
sudo iptables -D OUTPUT -o eth0 -p tcp -m tcp --dport 53 -j ACCEPT

To manually restart the openvpn connection. you’ll need to issue:

sudo iptables -A OUTPUT -o eth0 -p udp -m udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -o eth0 -p tcp -m tcp --dport 53 -j ACCEPT
sudo systemctl restart openvpn

/usr/local/sbin/watchdog.sh should be updated to:

#!/bin/bash
GW=$(ip route show 0.0.0.0/1 dev tun0 | cut -d\  -f3)
ping -c1 $GW > /dev/null
if [ $? -eq 0 ]
  then
    echo ok
    exit 0
  else
    systemctl stop openvpn
    sudo iptables -A OUTPUT -o eth0 -p udp -m udp --dport 53 -j ACCEPT
    sudo iptables -A OUTPUT -o eth0 -p tcp -m tcp --dport 53 -j ACCEPT
    sleep 5
    systemctl start openvpn
    sleep 5
    sudo iptables -D OUTPUT -o eth0 -p udp -m udp --dport 53 -j ACCEPT
    sudo iptables -D OUTPUT -o eth0 -p tcp -m tcp --dport 53 -j ACCEPT
fi

Regards Tom.

MarchHare · 19 November 2021 15:14

That could be the case, but then it must have always given the right IP block DNS servers because I never had 2 servers and they always matched the same IP block.

Tom_Doyle:

All I can suggest is removing the iptables rules allowing outbound dns requests via eth0 once the the VPN connection up. So once the connection is up issue:
sudo iptables -D OUTPUT -o eth0 -p udp -m udp --dport 53 -j ACCEPT
sudo iptables -D OUTPUT -o eth0 -p tcp -m tcp --dport 53 -j ACCEPT
To manually restart the openvpn connection. you’ll need to issue:
sudo iptables -A OUTPUT -o eth0 -p udp -m udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -o eth0 -p tcp -m tcp --dport 53 -j ACCEPT
sudo systemctl restart openvpn
/usr/local/sbin/watchdog.sh should be updated to:

This might be the solution. But what if I restart my Vero? Or when it crashes? Restarting happens pretty often, crashing a little less but a several times year I have to hard reboot the device for some reason like a green screen or if it gets stuck.
I could be wrong but I don’t think it will connect if watchdog didn’t add the iptables rules after a crash or restart and I would have to SSH in every time that happened to add the rules and start it manually.
Is there a way to run a check on start up of the device? that way the VPN can connect and watchdog will take over and delete or add the iptable rules once it connects or disconnects.

Tom_Doyle · 19 November 2021 16:09

Hi,

All I can suggest is starting the openvpn with the watchdog instead. First make sure the dns rules are not present in iptables, so out sudo iptables -S should look like this:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A OUTPUT -o tun0 -j ACCEPT
-A OUTPUT -o eth0 -p icmp -j ACCEPT
-A OUTPUT -d 192.168.1.0/24 -o eth0 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 22 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 123 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 1197 -j ACCEPT
-A OUTPUT -o eth0 -j DROP

Save these rules with: sudo netfilter-persistent save

disable openvpn on startup: sudo systemctl disable openvpn
Make the watchdog run on startup: sudo systemctl enable openvpn-watchdog

Then reboot. As long as the watchdog is as I posted above, I believe openvpn should start as expected.

Thanks Tom.

ZacWolf · 21 October 2022 20:38

Sorry to revive an old thread, but it came up while I was doing a search for how to set this all up myself.

I put together a guide to how I did it. Instead of installing the various OpenVPN “helper” systemd services, and/or mucking about with a script that updates resolv.conf and modifies iptables, just leverage the systemd-resolved service to do the heavy lifting.

In a nutshell, by symlinking /etc/resolv.conf to a version that comes with systemd-resolved, Network Manager will always do its lookups against 127.0.0.53, which links back to the systemd-resolved service. Then in your OpenVPN client.conf you “up” link to a matching script that adds the DNS servers to use while the tun interfaces is active.

debian - How to configure OpenVPN client to use different DNS servers when connected - Unix & Linux Stack Exchange

Another option, if you’re truly paranoid is to use a service called “unbound” which bypasses DNS and does a query of the domain registrar’s nameserver for every domain lookup.