Not working when run in a custom network - "dial tcp: i/o timeout" error #91

michaelnemtsev · 2020-06-14T14:37:11Z

Describe the bug
The container cannot connect to a server if a custom network is used and the container is created within that network

To Reproduce using docker CLI
docker network create vpn_network

docker run -ti --cap-add=NET_ADMIN --cap-add=SYS_MODULE --device /dev/net/tun --name nordvpn --net=vpn_network --sysctl net.ipv4.conf.all.rp_filter=2 -p 1194:1194 -e NETWORK=192.168.1.0/24 -e USER= -e PASS= -e CONNECT= -e TECHNOLOGY=NordLynx -d bubuntux/nordvpn

Expected behavior
NordVPN connection should be established but there are errors instead

Additional context
The purpose of using NordVPN docker this way is to integrate it with OpenVPN docker container to work together.
The use of "--net=container:" is not working in such scenario because all connected OpenVPN clients don't have internet connection

timmillwood · 2020-06-15T08:33:00Z

Same here as of today. Was working ok last week.

fredericrous · 2020-06-17T07:20:27Z

apparently nordvpn has issue with their api or changed it https://api.nordvpn.com/v1/servers/countries returns NULL
EDIT: It's back now.. idk if you were facing the same issue

d-tork · 2020-06-19T13:28:43Z

Getting the same. This is the first time I'm using the image so I can't verify it was working before.

Also, even though I pass the credentials when creating the container, it still asks for them at runtime.

rg-p · 2020-06-21T19:18:36Z

I hope this fix also works for this issue, correct me if I'm wrong. #78 (comment)

jasonm4130 · 2020-06-25T01:51:15Z

Been struggling with this issue too.

After looking into it, I think it may be to do with lines 34 - 39 of start_vpn.sh

if [[ -n ${DOCKER_NET} ]]; then
	iptables -A INPUT -s ${DOCKER_NET} -j ACCEPT
	iptables -A FORWARD -d ${DOCKER_NET} -j ACCEPT
	iptables -A FORWARD -s ${DOCKER_NET} -j ACCEPT
	iptables -A OUTPUT -d ${DOCKER_NET} -j ACCEPT
fi

From my limited understanding, the docker network isn't being defined so these lines are never run.
In turn a source and destination rule is never added for your network, so the container effectively has no internet.

Again this is limited knowledge, hopefully it helps someone progress this more.

Friday13th87 · 2020-06-28T13:42:09Z

hey there.
i tried to add this nordvpn container to my existing environment with a lot of containers - so i need to use my created networks as well and found me with the exact same issue discussed here.

what i did to get it working is, i added a link to a persistent /etc/resolv.conf i created before:
volumes:
- /path/to/resolv.conf:/etc/resolv.conf

just like that or -v /path/to/resolv.conf:/etc/resolv.conf
depending on how u are starting the container.

in my resolv.conf i just defined a DNS server to use and afterwards the container can resolv the domains

hope that workaround is helping you

timmillwood · 2020-06-30T17:48:42Z

The resolv.conf is overwritten with:

# Generated by NordVPN
nameserver 103.86.96.100
nameserver 103.86.99.100

Friday13th87 · 2020-06-30T17:54:29Z

you only need the file for the first initialization. afterwards you have the nameservers set by nordvpn depending on your las choosen country/server and they are working.

So you did what i said i assume and the container was running propably, otherwise it wouldnt have overritten the resolv.conf file. if you like to use a specific dns server, just run the nordvpn container with a certain user is ( user: "1000:1000" for example ) and set the file to read only.

but you should be good 2 go now, only thing whats not working is if 127.0.0.1 or 127.0.0.11 in the resolv.conf file and thats only at the first run of the container.

hot22shot · 2020-07-03T08:45:57Z

I have the same issue, running on a Synology NAS, I'm using the example docker-compose file.

ebbeknudsen · 2020-07-07T21:31:05Z

hey there.
i tried to add this nordvpn container to my existing environment with a lot of containers - so i need to use my created networks as well and found me with the exact same issue discussed here.

what i did to get it working is, i added a link to a persistent /etc/resolv.conf i created before:
volumes:

/path/to/resolv.conf:/etc/resolv.conf

just like that or -v /path/to/resolv.conf:/etc/resolv.conf
depending on how u are starting the container.

in my resolv.conf i just defined a DNS server to use and afterwards the container can resolv the domains

hope that workaround is helping you

I have the same problem using traefik as a web proxy, on a custom network.

Mind explaining how you defined the DNS server in resolv.conf? What did your file look like?

xkoldxx · 2020-07-10T02:50:52Z

Has anyone figured this out? This configuration worked for several months and has recently broken :/

vpn:
container_name: vpn
image: bubuntux/nordvpn
cap_add:
- net_admin
- SYS_MODULE
sysctls:
- net.ipv4.conf.all.rp_filter=2
devices:
- /dev/net/tun # Required
environment: # Review https://github.com/bubuntux/nordvpn#environment-variables
- USER=${USER}
- PASS=${PASS}
- CONNECT='us -g p2p' #United_States ### NORDLYNX
- TECHNOLOGY=NordLynx ### NORDLYNX
- NETWORK=${INTERNAL_NETWORKS}
- DEBUG=on ### NORDLYNX
- OPENVPN_OPTS=--mute-replay-warnings --mssfix 1432, --pull-filter ignore "ping-restart" --ping-exit 180
- PUID=99
- PGID=100
- TZ=America/Los_Angeles
- GROUPID=100
restart: unless-stopped
privileged: true
networks:
br0.100:
ipv4_address: 192.168.x.x

MervisDiamonds · 2020-07-12T12:24:34Z

I think I fixed it by using setting the DNS environment to Nord's namesevers.

Aaron- · 2020-07-30T14:57:37Z

Same issue here, when connecting via OpenVPN 2 routes are created:
0.0.0.0/1 via 10.8.1.1 dev tun0
128.0.0.0/1 via 10.8.1.1 dev tun0

When connecting over Wireguard/Nordlynx those routes are not created, however when manually creating the routes it works:
ip route add 0.0.0.0/1 via [insert vpn client ip] dev nordlynx
ip route add 128.0.0.0/1 via [insert vpn client ip] dev nordlynx

stevenjev · 2020-08-04T03:49:54Z

I was able to fix this issue by using the dns flag to add a DNS server such as 1.1.1.1 or 8.8.8.8, without using the other suggestions such as modifying resolv.conf.

--dns 1.1.1.1

rooseveltrp · 2020-08-21T06:09:38Z

I was able to fix this issue by using the dns flag to add a DNS server such as 1.1.1.1 or 8.8.8.8, without using the other suggestions such as modifying resolv.conf.

--dns 1.1.1.1

If you still have it, can you paste your docker compose file?

slimcdk · 2020-08-21T17:18:02Z

I get the errors (from /var/log/nordvpn/daemon.log in container)

2020/08/21 18:48:34 Post "https://zwyr157wwiu6eior.com/v1/users/tokens": dial tcp: i/o timeout
2020/08/21 18:48:38 Get "https://zwyr157wwiu6eior.com/v1/servers/countries": dial tcp: i/o timeout
2020/08/21 18:48:39 Post "https://boi9osyg1uwtyafn.com/v1/users/tokens": dial tcp: i/o timeout
2020/08/21 18:48:43 Get "https://x9fnzrtl4x8pynsf.com/v1/servers/countries": dial tcp: i/o timeout
2020/08/21 18:48:44 Post "https://icpsuawn1zy5amys.com/v1/users/tokens": dial tcp: i/o timeout
2020/08/21 18:48:48 Get "https://2ohvff3e8v46kb8.info/v1/servers/countries": dial tcp: i/o timeout
2020/08/21 18:48:49 Post "https://4qlnp8csnrj5zla.me/v1/users/tokens": dial tcp: i/o timeout
2020/08/21 18:48:53 Get "https://q8uvnsgljgste3f.info/v1/servers/countries": dial tcp: i/o timeout
2020/08/21 18:48:54 Post "https://w569ut7zbkiqf5b.xyz/v1/users/tokens": dial tcp: i/o timeout
2020/08/21 18:49:18 Get "https://w569ut7zbkiqf5b.xyz/v1/helpers/ips/insights": dial tcp: i/o timeout

This is my docker compose config:

  nordvpn:
    image: bubuntux/nordvpn:latest
    container_name: nordvpn
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    sysctls:
      - net.ipv4.conf.all.rp_filter=2
    devices:
      - /dev/net/tun
    environment:
      - TZ=${TZ}
      - PUID=${PUID}
      - PGID=${PGID}
      - USER=${VPN_USERNAME}
      - PASS=${VPN_PASSWORD}
      - CONNECT=${VPN_CONNECT}
      - TECHNOLOGY=NordLynx
      - NETWORK=192.168.1.0/24
    ports:
      - <list of ports that I use>
    restart: unless-stopped

It did also not work to map /etc/resolv.conf into the container

    volumes:
      - /etc/resolv.conf:/etc/resolv.conf:ro

What helped me, was to put the network into bridge mode.

    network_mode: bridge

From inside the container I can now do curl ifconfig.co to retrieve my external IP. Couldn't ping anything on WAN before I added network_mode: bridge

obbardc · 2020-09-27T10:40:54Z

+1, adding network_mode: bridge to the nordvpn container worked ;-)

andrewklajman · 2020-11-03T19:09:37Z

Apologies if i am out of my depth here.
network_mode: bridge does work for me as well. But I specifically want to define my own network so that I can assign static ip's to the containers.
Why do you have to use network_mode: bridge (my user defined network is also a bridge)? Or is there some way you can set an ip address when it is set to network_mode: bridge?

slimcdk · 2020-11-03T20:13:47Z

@andrewklajman There might be real world scenarios where you want static IP's, but what would the purpose be? If your containers are on same Docker network you can use multicast DNS for intercommunication instead of IPs

andrewklajman · 2020-11-03T21:12:07Z

I am going overseas and want to be able to access files and containers on my server. I setup a WireGuard VPN server to do this and it is working well with most things. But I want to be able to access the transmission web interface via my WireGuard setup and have the transmission torrent traffic through nordvpn.
I was able to achieve this by adjusting the iptables on the WireGuard VPN server to direct to the NordVPN/Transmission container. But iptables only lets you forward to an ip address and not a host name (as far as I know). Im concerned that the ip address might change.
Im not quite certain what multicast dns is but ill read up on it.
Thanks

slimcdk · 2020-11-03T21:31:34Z

Is your NordVPN/Transmission and WireGuard container connected to same Docker network? If so, you should be able to just type http://transmission:9091 (or whatever port you are using) in the browser and it will lookup the transmission hostname and show you the page.
If it is not the case, you could expose the NordVPN/Transmission ports to your local network and use the IP of your Docker host to access the webpage, e.g. http://192.168.1.10:9091

Another solution could be to expose the transmission service to the external network (port forwarding in your router). Then you got the possibility to access it using your networks public IP and the port you choose to port forward to 9091. Make sure to set a static IP for your Docker host and also enable access control for transmission.

andrewklajman · 2020-11-04T14:00:17Z

@slimcdk , yeah its on the same network. To be clear when I am connected to the network I can just type in the host name like you said just fine. But when I am on the WireGuard network I have to forward the request from the WireGuard VPN to the Transmission container (because the transmission container is not a WireGuard peer). The request forwards I have setup with iptables which is not going to allow me to forward to a host name (I have to put in an IP). My concern is that the IP could change and I was hoping there would be a more robust method to go about this.

I kind of feel like I am butchering my explanation of what I am trying to achieve so i have put a diagram to https://pastebin.com/4vDyjyqJ if that is easier to follow.

I dont think that this is a big problem since it does appear that the IP's are assigned according to the order of the containers in the docker compose file. Plus, I'm not sure of the likelihood of IP's changing once docker has assigned them.

Im not sure if there is anything else you can provide to me. I'm kinda new at networking and just following tutorials online so I may not understand (but am willing to read up on it).

Thanks

Edit - In the diagram above I just noticed that i mistakenly put the wrong port in the ip tables. It is '-to 172.1.1.2:9091'

Daniel15 · 2021-01-09T17:25:49Z

I've been looking into this and it seems to be due to the iptables rules in start_vpn.sh not allowing access to Docker's DNS server. If I just run this Docker image with a shell:

docker run --rm -ti --cap-add=NET_ADMIN --cap-add=SYS_MODULE --device /dev/net/tun --name vpn --sysctl net.ipv4.conf.all.rp_filter=2 -e USER=xxxxx@xxxxx.xx -e PASS='xxxxxxxxxxxxxxxxxxxxxx' -e CONNECT=US -e TECHNOLOGY=NordLynx --network=danbridge bubuntux/nordvpn /bin/sh

sg vpn -c 'curl 1.1.1.1' and sg vpn -c 'curl icanhazip.com' both work. If I then run /usr/bin/start_vpn.sh and open a new shell for the container, eg:

docker exec -it 5d685db8a811 /bin/sh

sg vpn -c 'curl 1.1.1.1' still works (meaning the container does still have internet connectivity), however sg vpn -c 'curl icanhazip.com' no longer works:

curl: (6) Could not resolve host: icanhazip.com

meaning DNS lookups are failing. Unfortunately neither ping nor nslookup nor traceroute are installed in the container which makes it hard to test further.

What's weird is that the script does appear to add iptables rules for the loopback interface to allow input, forward, and output:

iptables -A INPUT -i lo -j ACCEPT
iptables -A FORWARD -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

and also explicitly allows connections from the vpn group (which is why sg is needed):

iptables -A OUTPUT -m owner --gid-owner vpn -j ACCEPT

So I'm not sure why this is failing.

What helped me, was to put the network into bridge mode.

The issue with this is that it uses the 'default' bridge, which has various limitations (eg. accessing other containers using their hostname doesn't work).

Daniel15 · 2021-01-09T18:01:08Z

So it turns out that allowing all DNS traffic fixes the issue:

iptables  -A OUTPUT -p udp -m udp --dport 53    -j ACCEPT

Submitted a PR #131 to fix it.

In the mean time, you can work around the issue by downloading my fixed start_vpn.sh from https://raw.githubusercontent.com/Daniel15/nordvpn-docker/dns-fix/start_vpn.sh, chmod +x it, then bind mount it in the Docker container to replace the script embedded in the container, eg:

    volumes:
      - /home/daniel/docker/start_vpn.sh:/usr/bin/start_vpn.sh

for docker-compose or -v "/home/daniel/docker/start_vpn.sh:/usr/bin/start_vpn.sh" for regular Docker.

For some reason I can only get OpenVPN working this way (TECHNOLOGY=OpenVPN). WireGuard (TECHNOLOGY=NordLynx) "connects" successfully but no data makes it through the tunnel.

Daniel15 · 2021-01-09T18:14:47Z

I'm not actually sure how NordLynx ever worked properly with this script:

	iptables -A OUTPUT -m owner --gid-owner vpn -j ACCEPT || {
		iptables  -A OUTPUT -p udp -m udp --dport 53    -j ACCEPT
		iptables  -A OUTPUT -p udp -m udp --dport 51820 -j ACCEPT
		iptables  -A OUTPUT -p tcp -m tcp --dport 1194  -j ACCEPT
		iptables  -A OUTPUT -p udp -m udp --dport 1194  -j ACCEPT
		iptables  -A OUTPUT -p tcp -m tcp --dport 443   -j ACCEPT
		iptables  -A OUTPUT -o eth0 -d api.nordvpn.com  -j ACCEPT
	}

iptables -A OUTPUT -m owner --gid-owner vpn -j ACCEPT succeeds, so none of the other iptables commands execute (arguably if the --gid-owner vpn rule always succeeds then the other lines are dead code that should be removed).

WireGuard is part of the Linux kernel, so it's not executing as an individual user, so the packets are never marked as coming from the vpn GID. Port 51820 needs to be allowed unconditionally in order for NordLynx to work. I updated my PR to handle that.

ghost · 2021-01-22T08:28:05Z

So it turns out that allowing all DNS traffic fixes the issue:
iptables  -A OUTPUT -p udp -m udp --dport 53    -j ACCEPT
Submitted a PR #131 to fix it.

As commented by @bubuntux in PR #131 (comment):

this change seems like would open a data leaking issue...

So I don't think that this would be a good idea either. However, as already stated above: Changing the /etc/resolv.conf solves the issue. It is only required to change this file once, as it will be overriden once the VPN is up. One way is to pass the resolv.conf from a volume. A much simpler way is to use docker inspect vpn | grep "ResolvConfPath". From your docker host, just edit the path returned from the command and modify it. After that just run docker exec vpn /bin/sh -c /usr/bin/start_vpn.sh and the container will be able to establish a connection to the NordVPN network.

Daniel15 · 2021-01-23T07:54:00Z

So I don't think that this would be a good idea either.

Whether it causes DNS leaks or not depends on how your DNS is configured.

However, as already stated above: Changing the /etc/resolv.conf solves the issue

It doesn't fully solve it, as you need to use Docker's dnsmasq resolver to be able to access other containers (eg using http://foo to access the container called "foo" from another container on the same virtual network). Using NordVPN's DNS servers breaks this functionality.

github-actions · 2021-09-13T09:22:38Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

michaelnemtsev added bug Something isn't working help wanted Extra attention is needed labels Jun 14, 2020

timmillwood mentioned this issue Jun 21, 2020

Unable to Log In to NordVPN on Linux #78

Closed

Daniel15 mentioned this issue Jan 9, 2021

Always allow port 53 (DNS) traffic to resolve issues when using custom network #131

Closed

ghost mentioned this issue Jan 31, 2021

Updating NordVPN binary and fix for #91 #139

Closed

github-actions bot added the Stale label Sep 13, 2021

github-actions bot closed this as completed Sep 21, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Not working when run in a custom network - "dial tcp: i/o timeout" error #91

Not working when run in a custom network - "dial tcp: i/o timeout" error #91

michaelnemtsev commented Jun 14, 2020

timmillwood commented Jun 15, 2020

fredericrous commented Jun 17, 2020 •

edited

d-tork commented Jun 19, 2020

rg-p commented Jun 21, 2020

jasonm4130 commented Jun 25, 2020

Friday13th87 commented Jun 28, 2020

timmillwood commented Jun 30, 2020

Friday13th87 commented Jun 30, 2020

hot22shot commented Jul 3, 2020

ebbeknudsen commented Jul 7, 2020

xkoldxx commented Jul 10, 2020 •

edited

MervisDiamonds commented Jul 12, 2020

Aaron- commented Jul 30, 2020

stevenjev commented Aug 4, 2020

rooseveltrp commented Aug 21, 2020

slimcdk commented Aug 21, 2020

obbardc commented Sep 27, 2020

andrewklajman commented Nov 3, 2020 •

edited

slimcdk commented Nov 3, 2020

andrewklajman commented Nov 3, 2020

slimcdk commented Nov 3, 2020

andrewklajman commented Nov 4, 2020 •

edited

Daniel15 commented Jan 9, 2021 •

edited

Daniel15 commented Jan 9, 2021 •

edited

Daniel15 commented Jan 9, 2021

ghost commented Jan 22, 2021

Daniel15 commented Jan 23, 2021 •

edited

github-actions bot commented Sep 13, 2021

Not working when run in a custom network - "dial tcp: i/o timeout" error #91

Not working when run in a custom network - "dial tcp: i/o timeout" error #91

Comments

michaelnemtsev commented Jun 14, 2020

timmillwood commented Jun 15, 2020

fredericrous commented Jun 17, 2020 • edited

d-tork commented Jun 19, 2020

rg-p commented Jun 21, 2020

jasonm4130 commented Jun 25, 2020

Friday13th87 commented Jun 28, 2020

timmillwood commented Jun 30, 2020

Friday13th87 commented Jun 30, 2020

hot22shot commented Jul 3, 2020

ebbeknudsen commented Jul 7, 2020

xkoldxx commented Jul 10, 2020 • edited

MervisDiamonds commented Jul 12, 2020

Aaron- commented Jul 30, 2020

stevenjev commented Aug 4, 2020

rooseveltrp commented Aug 21, 2020

slimcdk commented Aug 21, 2020

obbardc commented Sep 27, 2020

andrewklajman commented Nov 3, 2020 • edited

slimcdk commented Nov 3, 2020

andrewklajman commented Nov 3, 2020

slimcdk commented Nov 3, 2020

andrewklajman commented Nov 4, 2020 • edited

Daniel15 commented Jan 9, 2021 • edited

Daniel15 commented Jan 9, 2021 • edited

Daniel15 commented Jan 9, 2021

ghost commented Jan 22, 2021

Daniel15 commented Jan 23, 2021 • edited

github-actions bot commented Sep 13, 2021

fredericrous commented Jun 17, 2020 •

edited

xkoldxx commented Jul 10, 2020 •

edited

andrewklajman commented Nov 3, 2020 •

edited

andrewklajman commented Nov 4, 2020 •

edited

Daniel15 commented Jan 9, 2021 •

edited

Daniel15 commented Jan 9, 2021 •

edited

Daniel15 commented Jan 23, 2021 •

edited