Jump to content
TorGuard

Search the Community

Showing results for tags 'dns'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • The Lounge
    • General Stuff
    • Member Tutorials
    • TorGuard Reviews
  • TorGuard Software Releases
    • Network Status
    • TorGuard Client Releases
    • Android Client Releases
    • iOS App Releases
    • Chrome Extension Releases
    • Firefox Extension Releases
  • TorGuard VPN Support
    • VPN Questions and General Support
    • VPN Windows Support
    • VPN Mac Support
    • VPN Linux Support
    • VPN Router Support
    • iOS VPN Support
    • Android VPN Support
  • TorGuard Proxy Support
    • Proxy Questions and General Support
    • Firefox Extension Support
    • Chrome Extension Support

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Found 21 results

  1. Dear Community, First you all know the drill by now - " The Intro " we would all have a better world if remembered to practice " Baby Love " lyrics : https://genius.com/Mothers-finest-baby-love-lyrics and video : https://www.youtube.com/watch?v=Z1LCj0Gkq94 Since version OPNsense 18.7 - you may install stubby and getdns on OPNsense by simply issuing command # pkg install getdns ( Special Thanks and Kudos to Franco and the marvelous OPNsense Development Team ) - Please disregard and do not use any guides and / or tutorials which pre-date this one which covers installation and configuration of DNS Privacy on OPNsense FireWall. This is an updated guide / tutorial which explains how to setup adding DNS-Over-TLS support for OPNsense. I run GetDns and Stubby forwarded to and integrated with Unbound. For those who wish to explore Stubby and GetDns - this method is the one recommended by DNSPRIVACY - see here : https://getdnsapi.net/ https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Clients#DNSPrivacyClients-Unbound - please read this carefully - you will note that it indicates : Unbound As A DNS TLS Client Features:Unbound can be run as a local caching forwarder, configured to use SSL upstream, however it cannot yet authenticate upstreams, re-use TCP/TLS connections, be configured for Opportunistic mode or send several of the privacy related options (padding, ECS privacy) etc. Some users combine Unbound (as a caching proxy with other features such as DNS Blacklisting) and Stubby (as a fully featured TLS forwarder). These are the reasons I choose to use GetDns and Stubby with Unbound. Those reasons being so that I can take full advantage of all of the most secure privacy features available when running DNS OVER TLS. What I give you here is the absolute best method of implementation and deployment of DNS OVER TLS. For any and all who may be wondering why DNS OVER TLS is all the rage - read this: https://tenta.com/blog/post/2017/12/dns-over-tls-vs-dnscrypt I always set up DNS OVER TLS first before configuring OpenVPN and / or WireGuard on OPNsense - this DNS solution works flawlessly with either VPN protocol. So here we go. So get ahead and issue command # pkg install getdns in order to get started. After installing getdns which includes stubby follow the steps below. 1 - Now Ryan Steinmetz aka zi - the port maintainer and developer of this port was kind enough to include a start up script ( stubby.in ) for this package. See the stubby.in here in the raw : https://svnweb.freebsd.org/ports/head/dns/getdns/files/stubby.in?view=markup. All I had to do was ask him and he did for any and all who elect to use this great piece of FreeBSD software. 2 - Now to put all of this together, The stubby.in file is located here - /usr/local/etc/rc.d/stubby by default. First though Stubby needs Unbound root.key - run this command before getting started: # su -m unbound -c /usr/local/sbin/unbound-anchor Then - A - Issue this command : # mv /usr/local/etc/rc.d/stubby /usr/local/etc/rc.d/stubby.sh Make it executable - I run two commands - it works for me: # chmod 744 /usr/local/etc/rc.d/stubby.sh # chmod a+x /usr/local/etc/rc.d/stubby.sh B - Yes must enable Stubby Daemon in the file - open file by : nano /usr/local/etc/rc.d/stubby.sh go to line 27 - : ${stubby_enable="NO"} change the setting to : ${stubby_enable="YES"} - that is all you have to do to this file. It comes pre-configured. Save and exit. 3 - You can and should also check real time status of DNS Privacy Servers as they are experimental and are not always stable - you can monitor DNS TLS Servers Real Time Status here below: https://dnsprivacy.org/jenkins/job/dnsprivacy-monitoring/ I have read here: https://www.monperrus.net/martin/randomization-encryption-dns-requests that Also, it is good to set up some servers that listens on port 443 and others on port 853, so as to be resilient if you are on a network with blocked ports. You can also blend IPv4 and IPv6 addresses. Now you must configure Stubby to resolve DNS OVER TLS - nano /usr/local/etc/stubby/stubby.yml VERY IMPORTANT UPDATE: After checking, rechecking and the triple checking on this website mentioned above : https://www.immuniweb.com/ssl/?id=Su8SeUQ4 I have made some very serious discoveries regarding which DNS Privacy Test Servers to use. The bottom line that I strongly suggest you only choose to deploy servers which support the TLSv1.3 protocol. See here for information and importance of TLSv1.3 : https://kinsta.com/blog/tls-1-3/ I will save you some considerable leg work and post below the best configuration for your stubby.yml file. Here it is: ## All DNS Privacy Servers Below Tested On https://www.immuniweb.com/ssl/?id=Su8SeUQ4 August 31 2019 With A+ Rating - 100% Perfecto Configuration nano /usr/local/etc/stubby/stubby.yml resolution_type: GETDNS_RESOLUTION_STUB dns_transport_list: - GETDNS_TRANSPORT_TLS tls_authentication: GETDNS_AUTHENTICATION_REQUIRED dnssec_return_status: GETDNS_EXTENSION_TRUE tls_query_padding_blocksize: 128 edns_client_subnet_private : 1 idle_timeout: 60000 listen_addresses: - [email protected] tls_connection_retries: 5 tls_backoff_time: 900 timeout: 2000 round_robin_upstreams: 1 tls_ca_path: "/etc/ssl/" upstream_recursive_servers: # IPV4 Servers ### DNS Privacy Test Servers ### ## The Surfnet/Sinodun DNS TLS Server A+ - address_data: 145.100.185.18 tls_port: 853 tls_auth_name: "dnsovertls3.sinodun.com" tls_pubkey_pinset: - digest: "sha256" value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8= ### Test servers ### #The DNS Warden DNS TLS Secondary Server A+ - address_data: 116.203.35.255 tls_auth_name: "dot2.dnswarden.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: aPns02lcGrDxnJQcRSHN8Cfx0XG+IXwqy5ishTQtzR0= #The dns.cmrg.net DNS TLS Server A+ - address_data: 199.58.81.218 tls_auth_name: "dns.cmrg.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo= #The BlahDNS German DNS TLS Server A+ - address_data: 159.69.198.101 tls_auth_name: "dot-de.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: sYrnkH4aRY6M9eP1Uut38GNTXK0xg7wD+Euy/xdW9xc= #The BlahDNS Japan DNS TLS Server A+ - address_data: 108.61.201.119 tls_auth_name: "dot-jp.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: psuldEImRyeSkU88b2ORtiNQ2uBdo+RCwAw6SxaJWQ4= # The securedns.eu DNS TLS Server A+ - address_data: 146.185.167.43 tls_auth_name: "dot.securedns.eu" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g= #The dns.neutopia.org DNS TLS Server A+ - address_data: 89.234.186.112 tls_auth_name: "dns.neutopia.org" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI= #The dns.seby.io - Vultr DNS TLS Server A+ - address_data: 139.99.222.72 tls_auth_name: "dot.seby.io" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 8A/1KQQiN+aFWenQon076nAINhlZjGkB15C4E/qogGw= #The Primary appliedprivacy.net DNS TLS Server A+ - address_data: 37.252.185.232 tls_auth_name: "dot1.appliedprivacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: MXKR+t7INx/SPe6RgmkIzRA2FvX+EDqTzTbhZcSBjas= #The Secure DNS Project by PumpleX DNS TLS Server A+ - address_data: 51.38.83.141 tls_auth_name: "dns.oszx.co" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: uXHfOKxBJ4aqMWmVw7+NtXGCkiYLyaeM7WujER0jIkM= #The dns.digitale-gesellschaft.ch DNS TLS Server # 1 A+ - address_data: 185.95.218.43 tls_auth_name: "dns.digitale-gesellschaft.ch" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: X2l8C7RQqcUFJ2OVKHn0cPnAoOE0UcvA13pDzJk7Z9c= #The dns.digitale-gesellschaft.ch DNS TLS Server # 2 A+ - address_data: 185.95.218.42 tls_auth_name: "dns.digitale-gesellschaft.ch" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 8j4m1FIePOXljzrKrm5EI27gRXfygvhCHfKwcApDGKs= #The doh.tiar.app DNS TLS Server A+ - address_data: 174.138.29.175 tls_auth_name: "doh.tiar.app" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: s5xofhW7O9egEANpOxvH7vRYndoDZOvNeq4i/91uopE= #The dns-nyc.aaflalo.me DNS TLS Server A+ - address_data: 168.235.81.167 tls_auth_name: "dns-nyc.aaflalo.me" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: KqzeDRgYePfKuZrKttwXM8I2Ej4kD6Sayh0kp4NWaJw= #The dns.aaflalo.me DNS TLS Server A+ - address_data: 176.56.236.175 tls_auth_name: "dns.aaflalo.me" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 50wqzG07SGqYwAO3NfzyrVq99wJZbhCWk0pu5VTc9n8= #The jp.tiar.app DNS TLS Server # 2 A+ - address_data: 172.104.93.80 tls_auth_name: "jp.tiar.app" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: rHMXX6yjgu62Z7QKtK6joQ3xHf8g/SJey8qiaXFdKKM= ### Anycast DNS Privacy Public Resolvers ### #The security-filter-dns.cleanbrowsing.org DNS TLS Server # 1 A+ - address_data: 185.228.168.9 tls_auth_name: "security-filter-dns.cleanbrowsing.org" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: rb2O6hMTZZ/go/vOqyVLY2lATD9DkD6+BkKfJwYYMFw= ## The DNS.SB DNS TLS Primary Server A+ - address_data: 185.222.222.222 tls_auth_name: "dns.sb" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k= ## The DNS.SB DNS TLS Secondary Server A+ - address_data: 185.184.222.222 tls_auth_name: "dns.sb" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k= Save and Exit All of these name servers listed above DO NOT log ! repeat DO NOT log ! your DNS queries. In full disclosure some name servers claim to log traffic volume only. See here for details : https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers and look under " Logging " column. Use either or both of these two methods to verify QNAME Minimisation A - Run command : drill txt qnamemintest.internet.nl and / or B - Run command: dig txt qnamemintest.internet.nl +short and / or dig -t txt qnamemintest.internet.nl ( for more complete readout including DNSSEC results ). AD = Authenticated Data (for DNSSEC only; indicates that the data was authenticated) The results in any of these scenarios will show either: "HOORAY - QNAME minimisation is enabled on your resolver !” or “NO - QNAME minimisation is NOT enabled on your resolver .” Reference https://discourse.pi-hole.net/t/unbound-and-qname-minimisation/10038/4 You will and should get HOORAY ! - if you used the name servers listed in this guide for your Stubby configuration. Note: Starting with Unbound 1.7.2 qname minimisation is enabled by default. However, I still add these settings manually. These settings are entered under Unbound " Custom Options": qname-minimisation: yes qname-minimisation-strict: yes harden-below-nxdomain: yes 4 - In order to have OPNsense use default start up script ( /usr/local/etc/rc.d/stubby.sh ) at boot time you will have to create a boot time start up script for it in /etc/rc.conf.d/. Not to prolong this - do the following : # nano /etc/rc.conf.d/stubby - in the new file enter the following two lines: stubby_enable="YES" stubby_bootup_run="/usr/local/etc/rc.d/stubby.sh" Save and exit / then make the file executable - once again - works for me : # chmod 744 /etc/rc.conf.d/stubby # chmod a+x /etc/rc.conf.d/stubby 5- Now you must configure your Unbound DNS Server to use Stubby for DNS Over TLS. UNBOUND GENERAL SETTINGS Network Interfaces = Select ALL ! Under Custom options enter the following : server: do-not-query-localhost: no forward-zone: name: "." # Allow all DNS queries forward-addr: [email protected] ## END OF ENTRY Outgoing Network Interfaces = Select ALL ! Make Sure to NOT CHECK - DO NOT CHECK - the box for DNS Query Forwarding. Save and Apply Settings Next -Under System > Settings > General Settings Set the first DNS Server to 127.0.0.1 with no gateway selected / Make sure that DNS server option A - Allow DNS server list to be overridden by DHCP/PPP on WAN - Is Not I repeat - Is Not Checked ! and DNS server option B - Do not use the DNS Forwarder/Resolver as a DNS server for the firewall Is Not - I repeat - Is Not Checked ! I now only run 127.0.0.1 ( Localhost ) configured as the only DNS SERVER on my WAN interface. If others were added to WAN, when I ran dig or drill commands /etc/resolv.conf allowed those addresses to be queried. I only want to use Stubby yml Name Servers for DNS TLS , so this was the determinative factor in my reasoning and decision. - Save and Apply Settings C'est Fini C'est Ci Bon C'est Magnifique Reboot your router just to sure. Lastly, you can check your DNS at GRC DNS Nameserver Spoofability Test - DNSLeak.com - or any such service. Your results will render the DNS PRIVACY Name Servers which you selected in your stubby.yml configuration file. You are now running DNS OVER TLS with GETDNS plus STUBBY ( a fully featured TLS forwarder ) along with an Unbound DNS Caching Server. VERY IMPORTANT TIP: Please note that right at the top of the main DNS Privacy Test Servers Homepage ( https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers ) It Ominously Declares: DoT servers The following servers are experimental DNS-over-TLS servers. Note that they are experimental offerings (mainly by individuals/small organisations) with no guarantees on the lifetime of the service, service level provided. The level of logging may also vary (see the individual websites where available) - the information here about logging has not been verified. Also note that the single SPKI pins published here for many of these servers are subject to change (e.g on Certificate renewal) and should be used with care!! For these reasons it is most important to check and verify your SPKI pin(s) for TLS authentication manually yourself from time to time. There are sure fire methods to make sure that you are using the correct value for any upstream nameserver ( aka tls_pubkey_pinset value ) - Go to https://blahdns.com/ and scroll down to the section to the yellow section entitled What is DNS OVER TLS click on it and it will open up. When you do it will state some general information, but what you want to pay attention to is this section: How to get SPKI gnutls-cli --print-cert -p 853 185.49.141.37 - where you must pkg install gnutls OR echo | openssl s_client -connect '185.49.141.37:853' 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64 Remember to change port to 443 or port for IPV6 if different than standard 853 where applicable. https://www.dnsleaktest.com/ https://www.perfect-privacy.com/dns-leaktest https://cryptoip.info/dns-leak-test https://www.grc.com/dns/dns.htm https://www.vpninsights.com/dns-leak-test and last but not least https://cmdns.dev.dns-oarc.net/ for a thorough in depth DNS Test https://bash.ws/dnsleak/test/ Now all you need to do is run is a properly configured VPN Service. By doing so, running DNS over TLS with Stubby and GetDns will keep your VPN provider from spying on your encrypted DNS look ups - and also your DNS providers both the ISP ( replaced by encrypted Stubby ) and your Encrypted TLS DNS Service Provider will see your IP as the one from your encrypted tunneled VPN provider. I am convinced this setup is the right strategy for both security and privacy. I think it to be the best practice for all those most serious about multi-layered cyber security. Special thanks to all who helped me with this project. Thank you all and God Bless Always In Peace, directnupe
  2. I recently started using the ad blocking DNS servers on TG. It makes a huge difference in browser performance as the ad-blocking at the DNS level prevents a lot of the adware leeches from sucking up your memory and CPU. Even pop-ups have ads disabled in them and sites don't seem to know that their ads are being block. No "Please disable your ad-blocker" messages. The only feature request I would ask from the @Support team is the ability for users to contribute blocking lists or show the list of trackers that currently being blocked. Otherwise a great feature. For anyone who wants to try it out, here are the instructions. https://torguard.net/blog/how-to-block-ads-with-torguard-vpn/
  3. JonnyQ

    DNS Security

    If a user selects Cloudflare or Google DNS in the client, does TorGuard connect to their services via DNS over TLS or DNS over HTTPS? This would be a huge privacy feature for TorGuard users.
  4. Was looking to find the best balanced settings for Torguard providing the most security with only a reasonable hit to throughput but could not find much details online. I decided to run some throughput tests on a few combinations of settings to determine the best option. The tests were done using speedtest.net using the same fixed remote server for all tests. In Torguard using the pin feature, I also fixed the VPN server IP for all tests. Throughput obviously varied based on server/ISP load but not by much. Also any test combinations where the numbers seemed to not make sense, I verified by doing the test again. Fixed Variables - Software Version - v3.90.0 - Used OpenVPN. I did test with OpenConnect with not much difference in speed and from the research so far OpenVPN is a more secure reliable option as of now. - Used UDP. TCP was about 40% slower than UDP and for general PC use losing a few packets has almost no noticeable effect. - Port - 1195 (SHA 256) - All other settings excluding the configuration changes listed below in the test were at default values. - Tests were done in order of security level (low to high) starting with Torguard completely disabled. Test Results Encryption Network Settings DL (Mbps) Loss Torguard Disabled Torguard Disabled 193 0% AES-128-CBC Default 164 15% AES-128-GCM Default 166 16% AES-256-CBC Default 160 20% AES-256-GCM Default 155 24% AES-256-CBC Block Outside DNS = On Name Server = None 163 19% AES-256-GCM Block Outside DNS = On Name Server = None 176 10% AES-256-CBC Block Outside DNS = On Name Server = VPN DNS 161 18% AES-256-GCM Block Outside DNS = On Name Server = VPN DNS 175 11% AES-256-CBC Block Outside DNS = On Name Server = Google 163 17% AES-256-GCM Block Outside DNS = On Name Server = Google 163 18% AES-256-CBC Block Outside DNS = Off Name Server = VPN DNS 164 18% AES-256-GCM Block Outside DNS = Off Name Server = VPN DNS 164 18% Summary -Using AES-256 vs AES-128 showed minor drop in throughput. -Adding the extra layers of security under DNS to prevent DNS resolve leaks had no negative impact on throughput. -Surprisingly after multiple repeat tests AES GCM (more secure) seems to provide better results using some of the DNS settings. Again there are obviously alot of other variables that would have impacted some of the results so they cannot be 100% accurate. It is also a limited test only taking 2 servers in to account but it does give a decent general idea as to what the best balanced options would be. Based on this test, the last configuration (in green) is the most secure option with a low amount of loss in throughput. Hope this helps any questions or corrections let me know.
  5. Hello All, I am the guy - directnupe - who wrote the guides - https://torguard.net/forums/index.php?/topic/1374-adding-dns-over-tls-support-to-openwrt-lede-with-unbound/ and https://forum.lede-project.org/t/adding-dns-over-tls-support-to-openwrt-lede-with-unbound/13765 . You also can leave out GETDNS and STUBBY see here: https://blog.grobox.de/2018/what-is-dns-privacy-and-how-to-set-it-up-for-openwrt/ # "read all guides to see how to install and run UNBOUND" Prerequisite You have a ca cert bundle installed on your router. You can do this by running the following opkg update / opkg install ca-certificates / opkg install luci-ssl For all of those who are using UNBOUND with tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt" # For OpenWrt option: This will have to wait until OpenSSL 1.1.x is included in OpenWrt/Lede or Unbound devs to find a way to validate it without using a function only available in OpenSSL 1.1.x - so the current OpenSSL version ( 1.0.2o ) does not support this feature. If you need more storage and swap memory for your router see here: http://ediy.com.my/index.php/blog/item/118-how-to-increase-storage-on-tp-link-tl-mr3020-with-extroot and here: https://samhobbs.co.uk/2013/11/more-space-for-packages-with-extroot-on-your-openwrt-router For DNS-Over-TLS support to OpenWRT (LEDE) with Unbound without GETDNS and STUBBY - see this article - https://www.ctrl.blog/entry/unbound-tls-forwarding and https://www.monperrus.net/martin/randomization-encryption-dns-requests In OpenWrt / Lede the ca-certificates package is located in /etc/ssl/certs/ca-certificates.crt much like Debian/Ubuntu. So actually as the title of the article says in order to " Actually secure DNS over TLS in Unbound " you should configure it thusly ( using Coudflare and Quad9 for this example - IPV4 and IPV6 if you so choose ) : First go into SSH shell and enter : nano /etc/unbound/unbound_srv.conf enter the following in the new file: server: do-tcp: yes prefetch: yes qname-minimisation: yes rrset-roundrobin: yes use-caps-for-id: yes tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt" # For OpenWrt Then hit ( Ctrl + o ) - you will be asked to write file - hit enter to save file then ( Ctrl + x ) to close file and go back into shell Next go into SSH shell and enter : nano /etc/unbound/unbound_ext.conf enter the following in the new file: forward-zone: name: "." forward-addr: 2620:fe::[email protected]#dns.quad9.net forward-addr: [email protected]#dns.quad9.net forward-addr: 2620:fe::[email protected]#dns.quad9.net forward-addr: [email protected]#dns.quad9.net forward-addr: 2606:4700:4700::[email protected]#cloudflare-dns.com forward-addr: [email protected]#cloudflare-dns.com forward-addr: 2606:4700:4700::[email protected]#cloudflare-dns.com forward-addr: [email protected]#cloudflare-dns.com forward-ssl-upstream: yes Then hit ( Ctrl + o ) - you will be asked to write file - hit enter to save file then ( Ctrl + x ) to close file and go back into shell I use GetDns Stubby and Unbound - so this is not how I employ DNS-Over-TLS ( see first 2 links above if you wish to take a look at that option ) Look at bottom of page on reddit post for related entry Peace, directnupe
  6. Cloudflare lunched privacy first DNS 1.1.1.1 and 1.0.0.1 You can find out more https://1.1.1.1 and https://news.ycombinator.com/item?id=16727869 I would love to hear thoughts on how are they comparing to TorGuard DNS?
  7. dopamine

    Warning: DNS Leaks

    Attention: TorGuard foreign servers in Switzerland and Iceland are leaking DNS data traceable to a US-based IP address. These connections are NOT secure. Please remember to ALWAYS use https://www.dnsleaktest.com to verify a secure connection.
  8. for the fields under the Network tap->DNS, i'm curious what others use here when adding their choice of DNS servers, like from OpenNIC, dnscrypt, etc? best practice to ensure anon DNS lookups and such. tia
  9. Looks like a nice 🕳ï¸, what's going on ? Since today I see more than 1 DNS server on DNS leak, these are all torguards, which I actually really like to see 8.0.11.12 DNS-8-0-11-15.Chicago1.Level3.net Level 3 Communications United States 8.0.11.15 cns3.Chicago2.Level3.net Level 3 Communications United States 8.0.11.0 DNS-8-0-11-8.Chicago1.Level3.net Level 3 Communications United States 8.0.10.6 DNS-8-0-11-11.Chicago1.Level3.net Level 3 Communications United States 8.0.10.11 DNS-8-0-11-9.Chicago1.Level3.net Level 3 Communications United States 8.0.10.7 DNS-8-0-10-1.Chicago1.Level3.net Level 3 Communications United States 8.0.11.8 DNS-8-0-11-14.Chicago1.Level3.net Level 3 Communications United States 8.0.10.3 DNS-8-0-11-4.Chicago1.Level3.net Level 3 Communications United States 8.0.10.13 DNS-8-0-10-2.Chicago1.Level3.net Level 3 Communications United States 8.0.10.1 DNS-8-0-11-6.Chicago1.Level3.net Level 3 Communications United States 8.0.11.11 DNS-8-0-10-12.Chicago1.Level3.net Level 3 Communications United States 8.0.11.9 DNS-8-0-10-6.Chicago1.Level3.net Level 3 Communications United States 8.0.10.9 DNS-8-0-10-11.Chicago1.Level3.net Level 3 Communications United States 8.0.11.7 DNS-8-0-11-12.Chicago1.Level3.net Level 3 Communications United States 8.0.11.14 DNS-8-0-10-3.Chicago1.Level3.net Level 3 Communications United States 8.0.11.4 DNS-8-0-10-7.Chicago1.Level3.net Level 3 Communications United States 8.0.10.2 DNS-8-0-10-9.Chicago1.Level3.net Level 3 Communications United States 8.0.11.6 DNS-8-0-10-13.Chicago1.Level3.net Level 3 Communications United States 8.0.10.12 DNS-8-0-11-7.Chicago1.Level3.net Level 3 Communications United States 8.0.11.5 DNS-8-0-11-5.Chicago1.Level3.net Level 3 Communications United States So, is it just on me/my server or is this implemented already on most servers?
  10. Check DNS requests guide (webarchive) In previous guide, I described how to get rid of your ISP or any other service (even TorGuard itself) hijacking your DNS (webarchive) In this topic I will show how you simply can find out what exactly is going on with port 53 which is default DNS port. Requierments HowTo/Wiki/Links Please read about tcpdump usage and how to on github, I will show here one exampe where I do check DNS requests on tun0 which is my openvpn tunnel connected to TorGuard. You can filter the command from the codebox below, but for simplicity, here it is: # tcpdump -vvv -i YOURINTERFACE port PORTNUMBER # Please lookup here for explanation of other options # - https://github.com/the-tcpdump-group/tcpdump tcpdump -vvv -i tun0 port 53 Logfile of test dump (it is long, that is why I'll put it into spoiler, for better overview) This is example of port 53 (DNS requests) when starting a stream on netflix US : (it will run until you stop it, you can do it by pressing CTRL+C on your keyboard) Results Here we received 26 packets and now we have clear DNS requests overview. What did we find? Let's take one line out of this log, this as example: 05:40:20.548149 IP (tos 0x0, ttl 64, id 59800, offset 0, flags [none], proto UDP (17), length 529) b.resolvers.Level3.net.53 > 10.35.0.6.25006: [udp sum ok] 38042 q: A? ipv4_1-lagg0-c158.1.ord001.ix.nflxvideo.net. 1/8/10 ipv4_1-lagg0-c158.1.ord001.ix.nflxvideo.net. [1h] A 108.175.38.188 ns: ix.nflxvideo.net. [3h48m5s] NS pdns154.ultradns.com., ix.nflxvideo.net. [3h48m5s] NS pdns154.ultradns.net., ix.nflxvideo.net. [3h48m5s] NS ns2.p30.dynect.net., ix.nflxvideo.net. [3h48m5s] NS ns3.p30.dynect.net., ix.nflxvideo.net. [3h48m5s] NS pdns154.ultradns.biz., ix.nflxvideo.net. [3h48m5s] NS pdns154.ultradns.org., ix.nflxvideo.net. [3h48m5s] NS ns4.p30.dynect.net., ix.nflxvideo.net. [3h48m5s] NS ns1.p30.dynect.net. ar: pdns154.ultradns.com. [1d19h29m25s] A 156.154.64.154, pdns154.ultradns.com. [16h59m27s] AAAA 2001:502:f3ff::be, ns3.p30.dynect.net. [3h48m10s] A 208.78.71.30, pdns154.ultradns.org. [15h27m14s] AAAA 2001:502:4612::be, ns4.p30.dynect.net. [3h48m10s] A 204.13.251.30, ns2.p30.dynect.net. [3h48m10s] A 204.13.250.30, pdns154.ultradns.net. [1d3h48m5s] A 156.154.65.154, pdns154.ultradns.net. [2h55m55s] AAAA 2610:a1:1014::be, pdns154.ultradns.biz. [15h27m14s] AAAA 2610:a1:1015::be, ns1.p30.dynect.net. [3h48m10s] A 208.78.70.30 (501) Basicly, all lines do the same if you take closer look, when you press play button on your browser, netflix does contact these servers on port 53. Choosen line in more understandable format Please do not think that preventing netflix to make this check (dns request) will help you with their service, this is not enough. But if you need to redirect anything, then this is how to get required information or simply to log your network. If there are requests, I'll write you a gui for Luci in openwrt where you can make these tests or whatever could be the goal of the requested app. You are free to discuss about your (or my ) results, check your ISP's and if you are conform with anything, well, listening to people on internet is not good, trying it out and doing yourself is good. At the end, whatever you want to do, you can automate it, ie. redirecting all these requests to your StreamIP (lol , this would have worked until the last crackdown but not anymore). Other services still work with that and there are plenty of streaming services. However, its good to know what your network does, at least on important ports like D Hope my terrible english is good enough for writting guides, but sorry for typos or some strange expressions.
  11. I have posted already how to prevent hijacking of your DNS by your IP. There are some ISP's like Verizon, T-Mobile, ... which do send all traffic over port 53 (yes, they hijack your DNS), regardless of which DNS servers you use. Here is how to get rid of that and redirect it to some another address with help of iptables instead editing dnsmasq in WebIF (which is still my preferable solution for most tasks), in this example I'll redirect all dns requests to my custom dns server, to lan1 in this case, which is my local DNS Server Openwrt (I think ddwrt should work too, but I did not test it on ddwrt but basicly it should be the same, just check the names of devices) iptables -t nat -A PREROUTING -i br-lan -p udp --dport 53 -j DNAT --to 192.168.1.1 On openwrt and other releases, switch on masquerading, it is required. Now a question to TorGuard, do you/can you offer alternative ports for those who maybe can't use first method described, neither this second solution. To find out what is going on through your DNS port, read here.
  12. The TG Vpn update of November 19, 2016 has somehow changed my Adapter Settings for my ethernet, wfi, and it's very own TAP windows adapter settings affecting no response from the DNS Server. So basically, I could not connect to the internet (by ethernet or wifi) and I figured it out by myself on how to fix the issue. I had to make sure that I had to change IPv4 and IPv6 Settings on said adapters to obtain IPv4 and IPv6 addresses and DNS Server Addresses automatically and it would fix the issue... BUT then the settings would change so I have to figure out which adapter had the settings changed, whether be it TG (TAP) adapter or my own Ethernet or wifi adapters, I have to manually fix it. Is this some kind of glitch??? or error?
  13. Hello, I'm trying to keep my DNS servers pointed to the TG servers: 104.223.91.194 104.223.91.210 91.121.113.58 91.121.113.7 In order to do this, I wrote a script for OSX #!/bin/bash sleep 5 networksetup -setdnsservers Wi-Fi 104.223.91.194 104.223.91.210 91.121.113.58 91.121.113.7 the script file has permissions: -r-xr-xr-x 1 username staff In some reason it doesn't set DNS after connection automatically. It requires me to run in manually with sudo from command line. Any idea what how to achieve that?
  14. jimmy j j

    DNS Problem

    Hello everyone, I'm on Ubuntu 16 and I have having a problem with the DNS on ipleak.net. When I use it on windows it will show the server in either france or sweden (I usually use stockholm). When I use it on here it shows around 20 or so IP's from the US. They are different than what I get when I don't use torguard however. The method I use is network connections, edit, ipv4, then I add the additional servers. It might have to do with this tunn connection that I see. Anyone have any ideas?
  15. rawl

    Smart dns release date?

    When will smart dns be released?
  16. TorGuard V 0.3.47 Debian jessie ISP AT&T I can't stop AT&T from hijacking my DNS requests. When I first connect with TorGuard (stop DNS blocking enabled) DNSLeakTest shows various DNS servers depending on what TorGuard server I use. But after a few minutes, anywhere from immediately to 30 mins, AT&T starts hijacking my DNS requests. Any suggestions? Thanks AT&T for you douchebaggery, but there is no reason you need to know what I'm doing. I f'n hate being tracked!
  17. On one of my devices I've been getting the following error all day long when I connect to torguard: "Blocking DNS Failed!" The connection is then dropped. This device has connected without issue in the past, and other devices are connecting as normal on the same network. I didn't change anything in the settings. Any suggestions? Edit: This problem seems to have been fixed by updating torguard. The auto-updater didn't show a new version until today.
  18. Samsung smart TV

    Samsung Smart TV setup

    Hey, I have a Samsung Smart TV that is about a year old. I can't seem to get the US version of netflix going (in australia). Does anyone know how to set this up? thanks.
  19. Please can anyone help me figure out why i am getting DNS leaks? I have set my network connections to use the torguard dns servers... still getting leaks.
  20. jimmy j j

    fixxing dns leak from ipleak

    Hello. While using both torguard lite and viscosity on the website ipleak.net I still get dns leaks. In a post a month or so ago the mention changing the dns to use a static one that is provided. I dont see a way to change it through both appliacations. Would I have to change it though windows and if I do, while I am not using a VPN will that affect anything. Also I am using firefrox and have changed the setting that allows for the RTC leak
  21. foobar

    DNS leak

    Hi, I've installed the Torguard app ( https://play.google.com/store/apps/details?id=net.torguard.openvpn.client) on my Android 4.2.2 The VPN is working but my DNS is leaking. I did my tests with https://dnsleaktest.com/ Does the application even try to change the DNS? Did you publish a guide or do you have suggestion on how to solve this problem? p.s. your service to test dns doesn't work, I think because it's an https page that tries to load some http content https://torguard.net/vpn-dns-leak-test.php
×