Surfshark vpn leak on linux

Question

I set up surfshark vpn today but seems amazon is able to detect it.

Your device is connected to the Internet using a VPN or proxy service. Please disable it and try again. For more help, go to amazon.com/pv-vpn.

I contacted customer support and changed my resolv.conf point to surfshark server manually but still not working.

How I can detect leak and config my vpn?

Update: Seems my dns is leaking. I'm trying to follow this post to fix my network but have not success yet.

mengo@mengo-desktop:~$ grep hosts /etc/nsswitch.conf
hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname
mengo@mengo-desktop:~$ head /etc/resolv.conf 
nameserver 162.252.172.57
nameserver 149.154.159.92
nameserver 162.252.172.57
nameserver 149.154.159.92
nameserver 127.0.0.53
mengo@mengo-desktop:~$ head /etc/resolvconf/interface-order
interface-order(5)
lo.inet6
lo.inet
lo.@(dnsmasq|pdnsd)
lo.!(pdns|pdns-recursor)
lo
tun*
tap*
hso*
vpn*
mengo@mengo-desktop:~$ cat /etc/NetworkManager/NetworkManager.conf 
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=false
[device]
wifi.scan-rand-mac-address=no

Update 2:

mengo@mengo-desktop:~$ resolvectl status
Global
...
   Current DNS Server: 162.252.172.57      
         DNS Servers: 162.252.172.57      
                      149.154.159.92
...
// This entry is shown when vpn is active
Link 3 (tun0)
      Current Scopes: none
DefaultRoute setting: no  
       LLMNR setting: yes 
MulticastDNS setting: no  
  DNSOverTLS setting: no  
      DNSSEC setting: no  
    DNSSEC supported: no
Link 2 (enp0s25)
...
  Current DNS Server: 192.168.1.1
         DNS Servers: 192.168.1.1
// connect vpn will create a new file tun0.openvpn which contains their server address
mengo@mengo-desktop:~$ ls /run/resolvconf/interface/
systemd-resolved  tun0.openvpn
mengo@mengo-desktop:~$ cat /run/resolvconf/interface/tun0.openvpn 
nameserver 162.252.172.57
nameserver 149.154.159.92
// I don't see vpn related entry here
mengo@mengo-desktop:~$ nmcli c show tun0 | grep -i dns
connection.mdns:                        -1 (default)
ipv4.dns:                               --
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      100
ipv4.ignore-auto-dns:                   no
ipv6.dns:                               --
ipv6.dns-search:                        --
ipv6.dns-options:                       --
ipv6.dns-priority:                      100
ipv6.ignore-auto-dns:                   no
// DNSOverTLS seems enabled by default
mengo@mengo-desktop:~$ cat /etc/systemd/resolved.conf | grep DNSOverTLS
#DNSOverTLS=no

Update 3 Seems some packets are log to console in either vpn is up or down. This happens periodically.

sudo tcpdump -i any -s0 -Knpvv host 192.168.1.1 and \(tcp port 53 or udp port 53\)
18:00:28.037630 IP (tos 0x0, ttl 64, id 35268, offset 0, flags [DF], proto UDP (17), length 86)
    192.168.1.24.42322 > 192.168.1.1.53: 62333+ [1au] AAAA? connectivity-check.ubuntu.com. ar: . OPT UDPsize=512 (58)
18:00:28.049945 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 147)
    192.168.1.1.53 > 192.168.1.24.42322: 62333 q: AAAA? connectivity-check.ubuntu.com. 0/1/1 ns: ubuntu.com. SOA ns1.canonical.com. hostmaster.canonical.com. 2018053142 10800 3600 604800 3600 ar: . OPT UDPsize=512 (119)
18:01:56.945889 IP (tos 0x0, ttl 64, id 37261, offset 0, flags [DF], proto UDP (17), length 86)
    192.168.1.24.50380 > 192.168.1.1.53: 11200+ [1au] A? connectivity-check.ubuntu.com. ar: . OPT UDPsize=512 (58)
18:01:56.958968 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 118)
    192.168.1.1.53 > 192.168.1.24.50380: 11200 q: A? connectivity-check.ubuntu.com. 2/0/1 connectivity-check.ubuntu.com. A 35.222.85.5, connectivity-check.ubuntu.com. A 35.224.99.156 ar: . OPT UDPsize=512 (90)

OS: linux mint 20.

Not necessarily detected: there are lists of IP addresses of VPN providers on the ent, they most likely are simply using those. This is especially the case if your VPN passed with flying colors the tests available on the internet, like https://tenta.com/test/. — MariusMatutiae, Sep 07 '20 at 05:55
Hi @MariusMatutiae, seems like my dns might be leaking, the link you shared somehow dns section is always loading, but I used several other site and seems thats the reason. I'll update my post with more information. — Mengo, Sep 07 '20 at 07:35
Setup Surfshark on ubuntu using the instructions at https://support.surfshark.com/hc/en-us/articles/360012109779-Connect-to-Surfshark-VPN-using-Ubuntu-Network-Manager The UI obviously varies slightly depending on your build and configuration but it should be fairly easy to follow. — M Steele, Dec 30 '20 at 20:20
So sorry to hear that, Surfshark works great for me. You can try using CyberGhost, it also works without any issues. — Maddy, Mar 25 '23 at 16:13

score 2 · Accepted Answer · answered Sep 07 '20 at 09:22

You currently have 5 nameserver entries in /etc/resolv.conf, 2 of which are duplicates. The maximum supported is usually 3 entries. This may not be the cause of your leak, but it might make your DNS resolution behave in undefined ways that make it hard to figure out what is going on. Or the extra entries might simply get ignored... but will the system use the first 3, or the last 3?

You also have 127.0.0.53 listed as the last entry, which indicates systemd-resolved.service may be present; please run systemctl status systemd-resolved to see if it is running, and if it is, resolvectl status to see which DNS servers it is configured to use; it may have a configuration that is different from /etc/resolv.conf.

And DNS leaks may have nothing to do with Amazon being able to detect your VPN. As MariusMatutiae commented, they may simply be detecting that the connection attempt comes from an IP address that is a known SurfShark exit point and refusing the connection because of just that.

Since /etc/resolvconf/interface-order exists on your system, that means resolvconf is probably installed. If that's true, ls /run/resolvconf/interface should display one or more files containing the DNS settings received via DHCP and/or other configuration methods. If activating SurfShark makes one more file appear in there, then SurfShark VPN client might be bypassing NetworkManager and you might need to adjust resolvconf settings to make it use SurfShark's settings exclusively when the VPN is active.

If there is just one file named NetworkManager in /run/resolvconf/interface/, then NetworkManager is the thing with overall control of the OS-level DNS configuration. In that case, some diagnostic steps would be:

run nmcli c show to see the names of all network connections known to NetworkManager. Is the SurfShark VPN listed in there?
if SurfShark is listed, note the name it's listed as, and then activate the SurfShark VPN and run nmcli c show "place the actual connection name of SurfShark VPN here" | grep -i dns. If the SurfShark VPN connection has provided any DNS server information for NetworkManager, this command should list it.

If neither of those approaches will show any DNS settings related to SurfShark, you should check whether or not the contents of /etc/resolv.conf and/or the output of resolvectl status will change when you enable/disable the SurfShark VPN. It might be that the VPN client is manipulating one or both of those directly.

If there are no apparent DNS settings changes associated with enabling/disabling the VPN anywhere, the SurfShark VPN client might be redirecting any DNS traffic at the kernel level to SurfShark servers. Depending on exactly how it is done, it may or may not be visible locally; in the most tricky case, you might need an external traffic sniffer to confirm that the DNS traffic is in fact redirected to SurfShark.

Also note that modern web browsers may use DNS-over-HTTPS or DNS-over-TLS. Those techniques will bypass the entire OS-level hostname resolving infrastructure and make direct encrypted connections to a DoH or DoT provider. This might be what your DNS leak tests are detecting.

(systemd-resolved may also use DNS-over-TLS if the DNSOverTLS setting is enabled in /etc/systemd/resolved.conf.)

Very appreciate your help! If my dns leak is from DoH or DoT, should I disable DoT flag? Please see my lasted updated post for more information. — Mengo, Sep 07 '20 at 22:07
Your resolvectl status seems to say that systemd-resolved's DNSOverTLS is already disabled for tun0. If it's the same for enp0s25, then you'll only need to worry about the browsers themselves. /run/resolvconf/interface/tun0.openvpn reveals that the 162.252.172.57 and 149.154.159.92 are SurfShark's DNS servers, so any queries going out to those addresses are not leaks. If any DNS queries are sent out through 192.168.1.1, that would be a leak. — telcoM, Sep 08 '20 at 05:35
Ah, I see DoT is disabled for both tun0 and enp0s25. How do I test if DNS query are send out through 192.168.1.1 or not? — Mengo, Sep 08 '20 at 08:25
You could use sudo tcpdump -i any -s0 -Knpvv host 192.168.1.1 and \(tcp port 53 or udp port 53\) to monitor network traffic: while the command is running, any DNS query packets from or to IP address 192.168.1.1 will be displayed. If you have this command running in a terminal while using a web browser, you will be able to see any outgoing DNS requests to 192.168.1.1 and also any replies. Press Control+C in the terminal window to stop the traffic dump. Note that you should start your web browser only after starting the VPN, to avoid it picking up the non-VPN DNS settings at startup. — telcoM, Sep 08 '20 at 09:13
Hi telcoM, I don't see any any log when either my vpn is up or down. Tried to restart browser before each test and read pcap-filter man page seems my syntax is correct. Is this expected? — Mengo, Sep 13 '20 at 00:51
wait, seems there is some logs in either case. I updated my post for this information. — Mengo, Sep 13 '20 at 01:05
I'm trying to disable connectivity check by adding a [connectivity] section and .set.enabled=false in /etc/NetworkManager/conf.d but didn't seem working. — Mengo, Sep 13 '20 at 01:59

Surfshark vpn leak on linux

interface-order(5)

1 Answers1

Linked