Cannot start -- start script output "Error: error sending query: Could not send or receive, because of network error"

[trireme32]

Synology docker container, latest.

All was working fine as of yesterday. When I went to open Deulge today, I noticed nothing was happening, so I restarted the container. Got the info below. Tried resetting the container, and rebooting the system. Same error every time.

2021-11-06 17:27:17.165216 [info] System information Linux binhex-arch-delugevpn1 4.4.59+ #25556 SMP PREEMPT Sat Aug 28 02:17:26 CST 2021 x86_64 GNU/Linux
2021-11-06 17:27:17.987809 [info] OS_ARCH defined as 'x86-64'
2021-11-06 17:27:18.354033 [info] PUID defined as '1037'
2021-11-06 17:27:18.784475 [info] PGID defined as '65537'
2021-11-06 17:27:23.207138 [warn] UMASK not defined (via -e UMASK), defaulting to '000'
2021-11-06 17:27:23.509939 [info] Permissions already set for volume mappings
2021-11-06 17:27:24.240384 [info] Deleting files in /tmp (non recursive)...
2021-11-06 17:27:24.431850 [info] VPN_ENABLED defined as 'yes'
2021-11-06 17:27:24.502140 [info] VPN_CLIENT defined as 'openvpn'
2021-11-06 17:27:24.568092 [info] VPN_PROV defined as 'pia'
2021-11-06 17:27:31.748309 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/CA Toronto.ovpn
2021-11-06 17:27:32.595478 [info] VPN remote server(s) defined as 'ca-toronto.privacy.network,'
2021-11-06 17:27:32.656899 [info] VPN remote port(s) defined as '1198,'
2021-11-06 17:27:32.718211 [info] VPN remote protcol(s) defined as 'udp,'
2021-11-06 17:27:32.785893 [info] VPN_DEVICE_TYPE defined as 'tun0'
2021-11-06 17:27:32.852760 [info] VPN_OPTIONS not defined (via -e VPN_OPTIONS)
2021-11-06 17:27:32.919861 [info] LAN_NETWORK defined as '192.168.1.0/24'
2021-11-06 17:27:32.986127 [info] NAME_SERVERS defined as '209.222.18.222,209.222.18.218'
2021-11-06 17:27:33.053937 [info] VPN_USER defined as 'SECRET'
2021-11-06 17:27:33.121422 [info] VPN_PASS defined as 'SECRET'
2021-11-06 17:27:33.188262 [info] STRICT_PORT_FORWARD defined as 'yes'
2021-11-06 17:27:33.255012 [warn] ENABLE_PRIVOXY not defined (via -e ENABLE_PRIVOXY), defaulting to 'no'
2021-11-06 17:27:33.328567 [info] VPN_INPUT_PORTS not defined (via -e VPN_INPUT_PORTS), skipping allow for custom incoming ports
2021-11-06 17:27:33.396362 [info] VPN_OUTPUT_PORTS not defined (via -e VPN_OUTPUT_PORTS), skipping allow for custom outgoing ports
2021-11-06 17:27:33.463788 [info] DELUGE_DAEMON_LOG_LEVEL not defined,(via -e DELUGE_DAEMON_LOG_LEVEL), defaulting to 'info'
2021-11-06 17:27:33.530880 [info] DELUGE_WEB_LOG_LEVEL not defined,(via -e DELUGE_WEB_LOG_LEVEL), defaulting to 'info'
2021-11-06 17:27:33.943198 [info] Starting Supervisor...
2021-11-06 17:28:05,814 INFO Included extra file "/etc/supervisor/conf.d/delugevpn.conf" during parsing
2021-11-06 17:28:05,814 INFO Set uid to user 0 succeeded
2021-11-06 17:28:06,766 INFO supervisord started with pid 8
2021-11-06 17:28:07,777 INFO spawned: 'shutdown-script' with pid 181
2021-11-06 17:28:07,779 INFO spawned: 'start-script' with pid 182
2021-11-06 17:28:07,806 INFO spawned: 'watchdog-script' with pid 184
2021-11-06 17:28:07,806 INFO reaped unknown pid 9 (exit status 0)
2021-11-06 17:28:08,007 DEBG 'start-script' stdout output:
[info] VPN is enabled, beginning configuration of VPN

2021-11-06 17:28:08,007 INFO success: shutdown-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2021-11-06 17:28:08,007 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2021-11-06 17:28:08,007 INFO success: watchdog-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2021-11-06 17:28:08,132 DEBG 'start-script' stdout output:
[info] Adding 209.222.18.222 to /etc/resolv.conf

2021-11-06 17:28:08,139 DEBG 'start-script' stdout output:
[info] Adding 209.222.18.218 to /etc/resolv.conf

2021-11-06 17:28:38,685 DEBG 'start-script' stderr output:
Error: error sending query: Could not send or receive, because of network error

That last part repeats a number of times and then it exits.

[binhex]

PIA DNS issues, please set NAME_SERVERS to the following:-

84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1

[TheOneOgre]

After updating the DNS, no longer getting network errors, instead getting

Unable to successfully download PIA json to generate token for wireguard from URL 'https://privateinternetaccess.com/gtoken/generateToken'

Seems to still be a PIA issue?

[binhex]

Seems to still be a PIA issue

Most probably yes, try another endpoint

[TheOneOgre]

Most probably yes, try another endpoint

Have tried nl-amsterdam, all the CA- ones, swiss- ,sweden-,uk-,monaco- none of them work so seems to be a widespread token generation issue.

Any way to monitor the status of it without manually restarting the container again and again hoping it connects?

[binhex]

Any way to monitor the status of it without manually restarting the container again and again hoping it connects?

just leave the container going it will continually retry, look in /config/supervisord.log to confirm its working or try the web ui, once the web ui is accessible you know the connection to the tunnel has been established.

[TheOneOgre]

just leave the container going it will continually retry, look in /config/supervisord.log to confirm its working or try the web ui, once the web ui is accessible you know the connection to the tunnel has been established.

This is the end of the code in log file, seems that the start script exits after failing the 12 retries and stops trying to reconnect.

2021-11-07 15:42:47,288 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token for wireguard from URL 'https://privateinternetaccess.com/gtoken/generateToken'
[info] 2 retries left
[info] Retrying in 10 secs...

2021-11-07 15:43:05,815 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token for wireguard from URL 'https://privateinternetaccess.com/gtoken/generateToken'
[info] 1 retries left
[info] Retrying in 10 secs...

2021-11-07 15:43:15,816 DEBG 'start-script' stdout output:
[crit] Unable to successfully download PIA json to generate token for wireguard, exiting script...

2021-11-07 15:43:15,817 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 22646109341968 for <Subprocess at 22646109341296 with name start-script in state RUNNING> (stdout)>
2021-11-07 15:43:15,817 DEBG fd 15 closed, stopped monitoring <POutputDispatcher at 22646109458640 for <Subprocess at 22646109341296 with name start-script in state RUNNING> (stderr)>
2021-11-07 15:43:15,817 INFO exited: start-script (exit status 1; not expected)
2021-11-07 15:43:15,817 DEBG received SIGCHLD indicating a child quit

[binhex]

hmm ok i thought i put in an infinite loop, its been a while sice i have stared at that particular code tbh, in any case i thought i would restart my container and for me i have no issues getting a pia token issued or a port assigned, this is for endpoint nl-amsterdam.privacy.network using wireguard, so not sure why you are seeing an issue, perhaps try the same endpint and check your subscrption hasnt expired

[TheOneOgre]

hmm ok i thought i put in an infinite loop, its been a while sice i have stared at that particular code tbh, in any case i thought i would restart my container and for me i have no issues getting a pia token issued or a port assigned, this is for endpoint nl-amsterdam.privacy.network using wireguard, so not sure why you are seeing an issue, perhaps try the same endpint and check your subscrption hasnt expired

Seems to have just come back online, just restarted the container without changing anything and now even the ca-ontario server is working properly

[pwright225]

PIA DNS issues, please set NAME_SERVERS to the following:-

84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1

just wanted to ask a question regarding this fix(meaning it worked for me), doesn't this create a dns leak? it seems to based on the test i ran, but how concerned should someone be about that?

[binhex]

NS lookup can only be performed over the VPN tunnel due to iptables therefore ensuring no ip leakage.

If of course you are using privoxy for your test then this will be the issue, privoxy is a HTTPS proxy only, i.e. name lookups will be sent over your ISP's connection.