Not sure my traffic is going over the VPN

[rdavey228]

Hello -

I have setup a custom provider with Cyberghost and I can see the VPN is working and connected to a server in Switzerland

Running the following command inside the container gives me a swiss ip address. So far so good!

curl -s checkip.dyndns.org | sed -e 's/.*Current IP Address: //' -e 's/<.*$//'

I have installed traceroute tools inside the container to check the route of the traffic.

The first hop is always shown as my ISP rather than the swiss IP. The swiss IP comes in second after my ISP. This leads me to believe DNS lookups are going over the VPN and going out to my ISP first!

Can anyone confirm this?

[mrjackyliang]

Did you specify the custom Google DNS?

[rdavey228]

No I removed that line....

Should the first hop be my ISP or the VPN?

[mrjackyliang]

The VPN should be connecting using Google’s DNS

[haugene]

If you don't override the dns it probably gets this from the host which gets it from your router which gets it from your ISP. The requests will still go through the VPN but your ISPs DNS servers will be used, i guess.

[rdavey228]

DHCP is set to use my internal DNS server which uses google as the DNS forwarders if it cant resolve it internally (which it obviously wont be able to for an external address)

I have changed the docker-compose file to use googles DNS any way as per coolboiime's comment. But my first hop is still a UK based address with the VPN being the next hop based in switzerland.

So this change made no difference......

[mrjackyliang]

What's the UK based IP address? I'm sure Google's DNS is spread out through a varities of CDN nodes.

Oh, and I forgot to add that if you're dialing out through an ADSL connection, that could also be the reason the first hop is local.

And let me know how you are debugging this, so I can figure out what's the issue.

[rdavey228]

Im running a trace route from inside the docker container

traceroute to bbc.co.uk (151.101.0.81), 30 hops max, 60 byte packets
 1  10.251.200.1 (10.251.200.1)  24.680 ms  24.611 ms  24.607 ms
 2  gw-104.datasource.ch (176.10.104.3)  103.595 ms  103.676 ms  103.817 ms
 3  hu-b69-10gigabit-slx9540.datasource.ch (91.201.56.132)  25.066 ms  25.190 ms  25.187 ms
 4  te0-2-1-3.rcr51.b021037-0.zrh02.atlas.cogentco.com (149.14.212.145)  26.708 ms  26.731 ms  26.742 ms
 5  be3592.ccr52.zrh02.atlas.cogentco.com (154.54.37.150)  26.730 ms  26.918 ms  26.915 ms
 6  be3072.ccr21.muc03.atlas.cogentco.com (130.117.0.18)  32.205 ms  32.887 ms be3073.ccr22.muc03.atlas.cogentco.com (130.117.0.62)  32.807 ms
 7  be2960.ccr42.fra03.atlas.cogentco.com (154.54.36.253)  37.958 ms  37.686 ms be2959.ccr41.fra03.atlas.cogentco.com (154.54.36.53)  38.116 ms

First IP is UK based, second IP is the VPN Provider.

Not on ADSL, I'm fibre to the premises using pppoe with BT being my ISP

[mrjackyliang]

PPPoE should be the reason why your network is hitting the BT DNS. This is one of the tactics many ISP providers check where your internet is being routed.

[rdavey228]

Really? Even though I dont set my ISPs DNS? I use my internal DNS server as the primary DNS for all devices on my network and that is designed to then forward any lookups to 8.8.8.8 and 8.8.4.4 if it cant resolve it internally. My router is also set to use 8.8.8.8 and 8.8.4.4 as its DNS servers as well....

[mrjackyliang]

Try this: https://www.dnsleaktest.com/

On Jul 24, 2018, at 2:35 AM, rdavey228 notifications@github.com wrote:

Really? Even though I dont set my ISPs DNS? I use my internal DNS server as the primary DNS for all devices on my network and that is designed to then forward any lookups to 8.8.8.8 and 8.8.4.4 if it cant resolve it internally. My router is also set to use 8.8.8.8 and 8.8.4.4 as its DNS servers as well....

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[rdavey228]

Thanks for the Suggestion to use DNS leak test but how can I do this from within side my VPN docker which is command line only.......

[mrjackyliang]

You would have to replicate the request on your computer. Simply route your computer through OpenVPN via Google's DNS, then use thw URL to check.

[ghost]

You can use the following to test this within the VPN docker https://github.com/macvk/dnsleaktest. Basically downloads a script that you run and provides the relevant details, external VPN IP address and the DNS server that you are potentially using. I have in the past used the method as described above connecting to the tinyproxy and then running the URL.

[rdavey228]

Ok so I ran the test from inside my container and these are the results

Your IP: 185.32.222.8 [Switzerland, Swiss Confederation, AS51395 SOFTplus Entwicklungen GmbH] Detected DNS servers: 172.217.40.3 [Netherlands, AS15169 Google LLC] 173.194.169.108 [Netherlands, AS15169 Google LLC] 173.194.170.2 [Netherlands, AS15169 Google LLC] 173.194.170.3 [Netherlands, AS15169 Google LLC] 173.194.170.9 [Netherlands, AS15169 Google LLC] 173.194.170.13 [Netherlands, AS15169 Google LLC] 173.194.170.108 [Netherlands, AS15169 Google LLC] Conclusion: DNS may be leaking.

Looks to me like everything is running through the swiss VPN right?

Although it says DNS may be leaking at the bottom.....

[ghost]

This looks like a DNS leak. You should have DNS servers listed that are supplied by your provider. Test a couple of other locations and see if you get the same results.

I use a CUSTOM connection as well and have found that some of my connections come back using the providers DNS servers while others show the google DNS servers. I tend to use the connections that only show the providers DNS servers.

An example of what I am talking about below with IP addresses removed but you get the idea. The AS numbers should be the same to be seen as not leaking.

Your IP: x.x.x.x [United Kingdom, AS13213 UK-2 Limited] Detected DNS servers: x.x.x.x [United Kingdom, AS13213 UK-2 Limited] Conclusion: DNS is not leaking.

[rdavey228]

The output from the logs seems to show that its getting DNS servers from Cyberghost

 VERIFY EKU OK
Mon Jul 30 10:57:45 2018 us=880061 VERIFY OK: depth=0, C=RO, L=Bucharest, O=CyberGhost S.A., CN=CyberGhost VPN Server Node huenenberg-s03, emailAddress=info@cyberghost.ro
Mon Jul 30 10:57:46 2018 us=13005 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Mon Jul 30 10:57:46 2018 us=13078 [CyberGhost VPN Server Node huenenberg-s03] Peer Connection Initiated with [AF_INET]185.32.222.5:443
Mon Jul 30 10:57:47 2018 us=128430 SENT CONTROL [CyberGhost VPN Server Node huenenberg-s03]: 'PUSH_REQUEST' (status=1)
Mon Jul 30 10:57:47 2018 us=157872 PUSH: Received control message: 'PUSH_REPLY,sndbuf 393216,rcvbuf 393216,comp-lzo no,redirect-gateway def1,dhcp-option DNS 194.187.251.67,dhcp-optio         n DNS 185.93.180.131,dhcp-option DNS 83.143.245.42,route 10.253.200.1,topology net30,ifconfig 10.253.202.130 10.253.202.129,peer-id 16,cipher AES-256-GCM'

but when I check resolv.conf it shows my local domain under search and 127.0.0.11 as the nameserver.

Cyberghost told me to put -

up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-conf

In my openvpn config file but then that stops transmission working as it needs to run tunnelup.sh as default so when I put in cyberghosts line it overrides the default UP script and transmission wont start. Even with putting in cyberghosts options it still shows I have a DNS leak.

[ghost]

I checked my resolv.conf and this shows me the google DNS servers that I added.

Looking at my set up, I am also using a docker compose file to set this and other containers up but I have added network_mode: bridge to use the default docker network. Tried to make this less complicated and keep the networking to a minimum. If I don't add this, there is an additional network created called scripts_default with an alternate subnet. In my case 172.18.0.0/16.

I recreated this without the above addition, and when checking the resolv.conf I see the same 127.0.0.11 for the name server address. Using the dnsleaktest script I still don't get a DNS leak connecting to the same location as before.

How you tried other locations beside Switzerland to see if you get the same results?

[rdavey228]

I have tried what you said - I have added google DNS to my docker-compose file but when I check resolve.conf i still get the 127.0.0.11 in there.

I checked with Cyberghost and they say that even though DNS leak test shows your DNS is leaking its most likely that its their DNS that is showing the leak rather than the DNS I am using meaning that I am still privately browsing. I dont know how much I trust that statement though....

This is my docker-compose file

services:
  vpn:
    image: haugene/transmission-openvpn
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    restart: always
    ports:
      - "9091:9091"
      - "8888:8888"
    dns:
      - 8.8.8.8
      - 8.8.4.4
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /mnt/dockervol/media/config/ovpn:/data
      - /mnt/dockervol/media/config/ovpn/cyberghost/config.ovpn:/etc/openvpn/custom/default.ovpn
      - /mnt/dockervol/media/config/ovpn/cyberghost:/etc/openvpn/cyberghost
      - /mnt/dockervol/media/media/downloads:/downloads
    environment:
      - PGID=1000
      - PUID=1000
      - OPENVPN_PROVIDER=CUSTOM
      - OPENVPN_USERNAME=*******
      - OPENVPN_PASSWORD=*******
      - OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60
      - LOCAL_NETWORK=172.28.0.0/20
      - TRANSMISSION_DOWNLOAD_DIR=/downloads/completed
      - TRANSMISSION_INCOMPLETE_DIR=/downloads/incomplete
      - TRANSMISSION_RATIO_LIMIT=0
      - TRANSMISSION_RATIO_LIMIT_ENABLED=true

Im not sure what these 2 lines actually do or if I need them. I just copied the config from online

cap_add:
  - NET_ADMIN
devices:
  - /dev/net/tun

[rdavey228]

Ok - Changed my network mode to Bridge and now resolve.conf shows google DNS. But DNS test still shows its leaking.

I will try another country and see what I get and post back

[ghost]

I have the same results. Some countries show the DNS leak others don't. I tend to just use the ones that don't as my preferred connections. I am still not sure if the google DNS servers should be listed in the resolv.conf just noticed the result with my set up.

[rdavey228]

Can you tell me which country's you use that dont show a DNS leak? That way I can use that country rather than keep trying different once till I come across one that does...?

[ghost]

It won't help as I am using a different VPN provider than yours. I ended up testing 4 random locations of where I wanted to be and then the ones that worked I use. I am connecting to the US and the UK.

[steffromfrance]

Hi Guys. In a previous development i have made a simple python script that check if a given IP (my public ip address) is exposed or not... it could be interesting in integrating it on the haugene container ? Whatever the problem is we could stop the container ?

[haugene]

This thread has discussed the topic quite well. There is also #698 that refers to many other issues like this on "how to verify traffic is going through VPN". So I'm closing this.

[ronaldmendoza]

Issue with DNS leaks still exists today on Mac Docker 2.2.0.3. Docker injects:

nameserver 127.0.0.11
options ndots:0

Naturally, we want to override this with the values from VPN provider. However, in /etc/openvpn/start.sh --up tunnelUp.sh, which conflicts with the typical way to rewrite resolv.conf in OpenVPN with nameservers from VPN: --up update-resolv-conf.

As a workaround to resolve this issue, I borrowed part of the code from this repo and modified tunnelUp.sh. Let me know if this is acceptable.

https://github.com/tlc/docker-openvpn-client-noleaks/blob/master/up2.sh

New script here:

#!/bin/bash
if [ "${PEER_DNS}" != "no" ]; then
        NS=
        DOMAIN=
        SEARCH=
        i=1
        while true ; do
                eval opt=\$foreign_option_${i}
                [ -z "${opt}" ] && break
                if [ "${opt}" != "${opt#dhcp-option DOMAIN *}" ] ; then
                        if [ -z "${DOMAIN}" ] ; then
                                DOMAIN="${opt#dhcp-option DOMAIN *}"
                        else
                                SEARCH="${SEARCH}${SEARCH:+ }${opt#dhcp-option DOMAIN *}"
                        fi
                elif [ "${opt}" != "${opt#dhcp-option DNS *}" ] ; then
                        NS="${NS}nameserver ${opt#dhcp-option DNS *}\n"
                fi
                i=$((${i} + 1))
        done
if [ -n "${NS}" ] ; then
                DNS="# Generated by openvpn for interface ${dev}\n"
                if [ -n "${SEARCH}" ] ; then
                        DNS="${DNS}search ${DOMAIN} ${SEARCH}\n"
                elif [ -n "${DOMAIN}" ]; then
                        DNS="${DNS}domain ${DOMAIN}\n"
                fi
                DNS="${DNS}${NS}"
                if [ -x /sbin/resolvconf ] ; then
                        printf "${DNS}" | /sbin/resolvconf -a "${dev}"
                else
                        # Preserve the existing resolv.conf
                        if [ -e /etc/resolv.conf ] ; then
                                cp /etc/resolv.conf /etc/resolv.conf-"${dev}".sv
                        fi
                        printf "${DNS}" > /etc/resolv.conf
                        chmod 644 /etc/resolv.conf
                fi
        fi
    # Remove the original default route to avoid leaks.
    route del default gw "${route_net_gateway}"
fi

/etc/transmission/start.sh "$@"
[[ ! -f /opt/tinyproxy/start.sh ]] || /opt/tinyproxy/start.sh

exit 0

[Cooper513]

Hi Guys. In a previous development i have made a simple python script that check if a given IP (my public ip address) is exposed or not... it could be interesting in integrating it on the haugene container ? Whatever the problem is we could stop the container ?

@sstassin I would be interested in this script! It's exactly what I am looking for. I'm using expressvpn. How can i obtain a copy?

[edgd1er]

@cooper, you could use nordvpn check, it may have a rate throttle: https://api.nordvpn.com/vpn/check/full or use https://www.myexternalip.com/raw to check that vpn ip is not your ip.

if you don't have a fixed ip, controls may be more difficult.

In this project, the default route is removed when the tun0 interface is up. Whenever the tun0 interface is down, no traffic is send to the gateway, unprotected. At this moment, no traffic should leak.

other idea, activate through OPENVPN_OPTIONS management interface, and with socat collect status every x minutes.