Synology Docker Cannot Resolve Host Address

[mhdesignmedia]

Hi,

After 2 days of banging my head I thought Id try some help on here! I have a Synology Docker running the latest build using PIA and am running into the following problem:

Using OpenVPN provider: PIA Starting OpenVPN using config France.ovpn Setting OPENVPN credentials... adding route to local network 192.168.1.0/24 via 172.17.0.1 dev eth0 Sun Jan 27 18:00:37 2019 OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018 Sun Jan 27 18:00:37 2019 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08 Sun Jan 27 18:00:37 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Sun Jan 27 18:00:37 2019 RESOLVE: Cannot resolve host address: france.privateinternetaccess.com:1198 (Temporary failure in name resolution) Sun Jan 27 18:00:37 2019 RESOLVE: Cannot resolve host address: france.privateinternetaccess.com:1198 (Temporary failure in name resolution) Sun Jan 27 18:00:37 2019 Could not determine IPv4/IPv6 protocol Sun Jan 27 18:00:37 2019 SIGUSR1[soft,init_instance] received, process restarting Sun Jan 27 18:00:42 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Sun Jan 27 18:00:42 2019 RESOLVE: Cannot resolve host address: france.privateinternetaccess.com:1198 (Temporary failure in name resolution) Sun Jan 27 18:00:42 2019 RESOLVE: Cannot resolve host address: france.privateinternetaccess.com:1198 (Temporary failure in name resolution) Sun Jan 27 18:00:42 2019 Could not determine IPv4/IPv6 protocol Sun Jan 27 18:00:42 2019 SIGUSR1[soft,init_instance] received, process restarting Sun Jan 27 18:00:47 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Sun Jan 27 18:00:47 2019 RESOLVE: Cannot resolve host address: france.privateinternetaccess.com:1198 (Temporary failure in name resolution) Sun Jan 27 18:00:47 2019 RESOLVE: Cannot resolve host address: france.privateinternetaccess.com:1198 (Temporary failure in name resolution) Sun Jan 27 18:00:47 2019 Could not determine IPv4/IPv6 protocol Sun Jan 27 18:00:47 2019 SIGUSR1[soft,init_instance] received, process restarting Sun Jan 27 18:00:52 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Sun Jan 27 18:00:52 2019 RESOLVE: Cannot resolve host address: france.privateinternetaccess.com:1198 (Temporary failure in name resolution) Sun Jan 27 18:00:52 2019 RESOLVE: Cannot resolve host address: france.privateinternetaccess.com:1198 (Temporary failure in name resolution) Sun Jan 27 18:00:52 2019 Could not determine IPv4/IPv6 protocol Sun Jan 27 18:00:52 2019 SIGUSR1[soft,init_instance] received, process restarting

Im using a modified resolv.conf that I found on here that uses the below as I thought it might be a DNS issue but still no joy. Any help anyone...PLEASE?

--dns 8.8.8.8 \ --dns 8.8.4.4 \

[haugene]

Yeah, this really sounds like a DNS issue. Are you using a modified resolv.conf in addition to those dns flags? Can you post your docker run command?

[mhdesignmedia]

The DNS flags are from my resolv.conf I found them from another post on here from a few months back. I might try changing them back to the default. My run command is the default one

Tested on DSM 6.1.4-15217 Update 1, Docker Package 17.05.0-0349

docker run \ --cap-add=NET_ADMIN \ --device=/dev/net/tun \ -d \ -v /volume1/foldername/resolv.conf:/etc/resolv.conf \ -v /volume1/yourpath/:/data \ -e "OPENVPN_PROVIDER=PIA" \ -e "OPENVPN_CONFIG=CA\ Toronto" \ -e "OPENVPN_USERNAME=XXXXX" \ -e "OPENVPN_PASSWORD=XXXXX" \ -e "LOCAL_NETWORK=192.168.0.0/24" \ -e "OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60" \ -e "PGID=100" \ -e "PUID=1234" \ -p 9091:9091 \ --sysctl net.ipv6.conf.all.disable_ipv6=0 \ --name "transmission-openvpn-syno" \ haugene/transmission-openvpn:latest

[haugene]

And what is the content of /volume1/foldername/resolv.conf?

--dns 8.8.8.8 
--dns 8.8.4.4 \

?

[mhdesignmedia]

Yep that’s the one, I’ll try changing back to default maybe?

[haugene]

You've just mixed up the two ways to add dns servers. One option is to add --dns 8.8.8.8 --dns 8.8.4.4 to your docker run command, then you shouldn't mount a resolv.conf file. Docker will add it.

Or you can skip the --dns flags in the docker run command and use a volume mount of resolv.conf instead. But then the contents should be on this form:

nameserver 8.8.8.8
nameserver 8.8.4.4

[mhdesignmedia]

Ah ok! I’ll give that a shot later when I’m home. Thanks for the help!

[haugene]

Np, keep me posted. Hopefully that solves it ;)

[mhdesignmedia]

All working - Thank you Kristian!!!

[haugene]

You're welcome :)

[mhdesignmedia]

Sorry Kristian one other thing - I don't suppose you would know why my torrents aren't seeding back? They have downloaded ok

[haugene]

Hmm. From what I see you're using PIA on port-forwarding enabled regions (https://www.privateinternetaccess.com/helpdesk/kb/articles/how-do-i-enable-port-forwarding-on-my-vpn). So it should work out of the box.

Check the logs. Does it say that it gets a port from PIA and that it is checked OK and is open? Apart from that I can't really see a reason why you shouldn't seed well. It's depending on the torrent and tracker as well of course, but should be similar to not running via VPN.

[mhdesignmedia]

This is the full log once I got it working yesterday;

2019-01-28 20:48:29	stdout	Port is open: Yes
2019-01-28 20:48:18	stdout	Checking port...
2019-01-28 20:48:18	stdout	localhost:9091/transmission/rpc/ responded: "success"
2019-01-28 20:48:18	stdout	transmission auth not required
2019-01-28 20:48:18	stdout	Got new port 44623 from PIA
2019-01-28 20:48:01	stdout	Wait for tunnel to be fully initialized and PIA is ready to give us a port
2019-01-28 20:48:01	stdout	Mon Jan 28 20:48:01 2019 Initialization Sequence Completed
2019-01-28 20:48:01	stdout	Transmission startup script complete.
2019-01-28 20:48:01	stdout	CONFIGURING PORT FORWARDING
2019-01-28 20:48:01	stdout	STARTING TRANSMISSION
2019-01-28 20:48:01	stdout
2019-01-28 20:48:01	stdout	-------------------------------------
2019-01-28 20:48:01	stdout	User gid:    101
2019-01-28 20:48:01	stdout	User uid:    1026
2019-01-28 20:48:01	stdout	User name:   abc
2019-01-28 20:48:01	stdout	-------------------------------------
2019-01-28 20:48:01	stdout	Transmission will run as
2019-01-28 20:48:01	stdout	-------------------------------------
2019-01-28 20:48:01	stdout
2019-01-28 20:48:00	stdout	Setting permission for files (644) and directories (755)
2019-01-28 20:47:59	stdout	Setting owner for transmission paths to 1026:101
2019-01-28 20:47:59	stdout	Applying permissions to transmission config directories
2019-01-28 20:47:59	stdout	Enforcing ownership on transmission config directories
2019-01-28 20:47:59	stdout	sed'ing True to true
2019-01-28 20:47:59	stdout	Generating transmission settings.json from env variables
2019-01-28 20:47:59	stdout	Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 10.60.10.6
2019-01-28 20:47:59	stdout	Up script executed with tun0 1500 1558 10.60.10.6 10.60.10.5 init
2019-01-28 20:47:59	stdout	Mon Jan 28 20:47:59 2019 /etc/openvpn/tunnelUp.sh tun0 1500 1558 10.60.10.6 10.60.10.5 init
2019-01-28 20:47:59	stdout	Mon Jan 28 20:47:59 2019 /sbin/ip addr add dev tun0 local 10.60.10.6 peer 10.60.10.5
2019-01-28 20:47:59	stdout	Mon Jan 28 20:47:59 2019 /sbin/ip link set dev tun0 up mtu 1500
2019-01-28 20:47:59	stdout	Mon Jan 28 20:47:59 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
2019-01-28 20:47:59	stdout	Mon Jan 28 20:47:59 2019 TUN/TAP device tun0 opened
2019-01-28 20:47:53	stdout	Mon Jan 28 20:47:53 2019 [3bcd6d04e22b3b0dc3d5d5c2c77f205c] Peer Connection Initiated with [AF_INET]194.187.249.185:1198
2019-01-28 20:47:53	stdout	Mon Jan 28 20:47:53 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2019-01-28 20:47:53	stdout	Mon Jan 28 20:47:53 2019 UDP link remote: [AF_INET]194.187.249.185:1198
2019-01-28 20:47:53	stdout	Mon Jan 28 20:47:53 2019 UDP link local: (not bound)
2019-01-28 20:47:53	stdout	Mon Jan 28 20:47:53 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]194.187.249.185:1198
2019-01-28 20:47:53	stdout	Mon Jan 28 20:47:53 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2019-01-28 20:47:53	stdout	Mon Jan 28 20:47:53 2019 library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08
2019-01-28 20:47:53	stdout	Mon Jan 28 20:47:53 2019 OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018
2019-01-28 20:47:53	stdout	adding route to local network 192.168.1.0/24 via 172.17.0.1 dev eth0
2019-01-28 20:47:52	stdout	Setting OPENVPN credentials...
2019-01-28 20:47:52	stdout	Starting OpenVPN using config France.ovpn
2019-01-28 20:47:52	stdout	Using OpenVPN provider: PIA
2019-01-28 20:47:33	stdout	Mon Jan 28 20:47:33 2019 SIGTERM[hard,] received, process exiting
2019-01-28 20:47:32	stdout	Mon Jan 28 20:47:32 2019 /etc/openvpn/tunnelDown.sh tun0 1500 1558 10.44.10.6 10.44.10.5 init
2019-01-28 20:47:32	stdout	Mon Jan 28 20:47:32 2019 /sbin/ip addr del dev tun0 local 10.44.10.6 peer 10.44.10.5
2019-01-28 20:47:32	stdout	Mon Jan 28 20:47:32 2019 event_wait : Interrupted system call (code=4)

I wonder if its some security setting on the Synology somewhere

[haugene]

Still no seeding? Never easy getting to the bottom of all network related things. But it seems the container is running as intended so I think I'll close this for now.

[mhdesignmedia]

Thanks for the help...it seems to be seeding but is very slow at the moment. Im going to try setting it up again and see how it goes.