Jump to content
TorGuard

All Activity

This stream auto-updates     

  1. Today
  2. NullTotality

    Port Forwarding not working

    Open your console and run this netsh command as admin: netsh interface portproxy add v4tov4 listenport=external_port listenaddress=0.0.0.0 connectport=internal_port connectaddress=127.0.0.1 You have to replace "external_port" and "internal_port" with the correct port numbers you're using.
  3. Gladonel

    Streaming IP stopped working no help

    I got my Netflix UK streaming IP stopped working but TorGuard's support was excellent and got my issue fixed in under 30 minutes.
  4. Yesterday
  5. CitizenSmith

    Torguard Speed Test Best Settings Speed vs Security

    Not that up on VPN configs could you please direct me! you say this is best security I'm assuming that includes for downloading torrents! AES-256-GCM Block Outside DNS = Off Name Server = VPN DNS 164 18% 1. To block outside DNS I go to "network tab"/ "DNS"/ and untick "block outside dns" which equals off is that correct. 2. And to do the Name Server I go to "Network tab"/ "DNS"/ "-when VPN is connected" and select "VPN DNS" there!. Thanks for help you can provide
  6. LAN Interface For GETDNS and STUBBY Plus UNBOUND WHY YOU ASK ? ANSWER : IN LIFE ONE SHOULD HAVE OPTIONS IMPORTANT UPDATED INFORMATION !!! - READ FULL GUIDE BEFORE GETTING STARTED !!! Stop pfSense Router from occasionally allowing UNBOUND Root Hints to resolve queries on its own. This configuration ensures that localhost ( 127.0.0.1 ) will not be used as a resolver on pfSense Box. You will only use GETDNS and STUBBY DNS SERVERS if you follow this tutorial. You will use your One Main LAN Interface as the listening interface for STUBBY and the listening and outgoing interface for your UNBOUND DNS RESOLVER on pfSense. So, let's get started. See Below For Definition and Function Of Unbound Root Hints : Unbound is a caching DNS resolver. It uses a built in list of authoritative nameservers for the root zone (.), the so called root hints. On receiving a DNS query it will ask the root nameservers for an answer and will in almost all cases receive a delegation to a top level domain (TLD) authoritative nameserver. Source Document : https://man.openbsd.org/unbound First you all know the drill by now - " The Intro " we would all have a better world if we remember to practice the concept that - NOW ! is the time for all of US ( A ) to GET UP & GET INVLOVED and act with SOUL POWER ! - lyrics to sing along : https://genius.com/James-brown-get-up-get-into-it-get-involved-lyrics plus https://genius.com/James-brown-soul-power-lyrics and video : https://www.youtube.com/watch?v=1pvIarW3xHg Bonus JB : https://www.youtube.com/watch?v=v8TvBPshngE - I noticed on https://www.freshports.org/dns/getdns/ that ever since getdns 1.5.2_1 - stubby is included in the package by default. PLEASE TAKE SPECIAL NOTE UNDER Commit History : - Update to 1.5.2 - Build with STUBBY by default due to popular demand This got me to thinking about how to install DNS Privacy DNS OVER TLS on pfSense ( Special Thanks and Kudos to Ryan Steinmetz aka zi - the port maintainer and developer getdns on FreeBSD ). This is an updated guide / tutorial which explains how to setup adding DNS-Over-TLS support for pfSense - 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 pfSense FireWall. 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). I was asked by a still skeptical devotee of DOH " What makes this way better than just running the DNS-over-https-proxy ? My answer was : Read this and make your decisions and conclusions concerning DOH vs DOT . Here is the article below : https://www.netmeister.org/blog/doh-dot-dnssec.html Short Synopsis of DOH: In other words , ( with DOH ) we gain the same protections as with DoT for our web applications, but leaves all other DNS traffic vulnerable. Subsequently, as a matter of fact and in practice with DNS OVER TLS ALL DNS traffic is invulnerable and protected.This is why I run DOT and eschew DOH on my pfSense Router. Further, Personally, I run GETDNS STUBBY and UNBOUND as described here along with ( wait for it ) FireFox DOH along with Encrypted SNI - plus TLS v 1.3 in Stubby and naturally a properly configured and encrypted VPN - 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 pfSense - this DNS solution works flawlessly with either VPN protocol. So here we go. 1 - There are four dependency packages required before actually installing the getdns package. Two are available in the pfSense package repositories and two from the FreeBSD repository. Lastly the getdns package itself is also in the FreeBSD repository. So to begin enter these commands below in the order : A # pkg install libuv B # pkg install libyaml - Go to https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/ as pfSense is based on FreeBSD 11 - C # pkg add https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libev-4.24,1.txz D # pkg add https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libidn-1.35.txz Lastly, install getdns along with stubby E # pkg add https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/getdns-1.5.2_4.txz GetDNS and Stubby are now installed on pfSense FireWall. In order to configure UNBOUND along with stubby ( and getdns ) follow the steps below. For pfSense 2.5.0 Development Snapshots which is based on FreeBSD 12 which includes openssl 1.1 with tls 1.3 support for Stubby get packages from pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/latest/All/ links for the same packages listed above - always check for latest packages first or you might encounter download issues. 2 - 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. 3 - 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. 4 - 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 and Updated On February 17 2020 With A+ Rating - 100% Perfecto Configuration on website: https://www.immuniweb.com/ssl/?id=Su8SeUQ4n ** These servers support the most recent and secure TLS protocol version of TLS 1.3 ** Good configuration - These server configurations support only TLSv1.2 and TLSv1.3 protocols - current most secure encryption. # Also I have added the Country Locations of These DNS PRIVACY Servers using the Alpha 3 Code Format # see country code lists here : # https://www.nationsonline.org/oneworld/country_code_list.htm or https://www.iban.com/country-codes # Use as many or as few depending on your specific needs ## Go Into SSH shell and enter : # 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: 9000 listen_addresses: - [email protected] ## Enter Your One Main LAN Address Here 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 ### ## 1 - The Surfnet/Sinodun DNS TLS Server #3 A+ ( NLD ) - address_data: 145.100.185.18 tls_port: 853 tls_auth_name: "dnsovertls3.sinodun.com" tls_pubkey_pinset: - digest: "sha256" value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8= ### Test servers ### ## 2 - The DNS Warden DNS TLS Server #1 A+ ( IND hosted in DEU ) - address_data: 116.203.70.156 tls_auth_name: "dot1.dnswarden.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: aPns02lcGrDxnJQcRSHN8Cfx0XG+IXwqy5ishTQtzR0= ## 3 - The DNS Warden DNS TLS Server #2 A+ ( IND hosted in DEU ) - address_data: 116.203.35.255 tls_auth_name: "dot2.dnswarden.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: aPns02lcGrDxnJQcRSHN8Cfx0XG+IXwqy5ishTQtzR0= ## 4 - The ContainerPI.com - CPI DNS TLS Server A+ ( JPN ) - address_data: 45.77.180.10 tls_auth_name: "dns.containerpi.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: xz8kGlumwEGkPwJ3QV/XlHRKCVNo2Fae8bM5YqlyvFs= ## 5 - The FEROZ SALAM DNS TLS Server A+ ( GBR ) - address_data: 46.101.66.244 tls_auth_name: "doh.li" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 0xvfP+YW1Ueh+CRKPxHRyPTK7HSMfgd1KvYAVwSZqbI= ## 6 - The Andrews & Arnold DNS TLS Server #1 A+ ( GBR ) - address_data: 217.169.20.23 tls_auth_name: "dns.aa.net.uk" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: QU5xobzrRJeiNVUXh0bpUO42Xwj1HQgZo/uA3Uztfhc= ## 7 - The Andrews & Arnold DNS TLS Server #2 A+ ( GBR ) - address_data: 217.169.20.22 tls_auth_name: "dns.aa.net.uk" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: SbMmQBuIp1HNX9FCCXuzHT0Nq4qnfwdwwH9i1/FYwT8= ## 8 - The dns.cmrg.net DNS TLS Server A+ ( CAN ) - address_data: 199.58.81.218 tls_auth_name: "dns.cmrg.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo= ## 9 - The BlahDNS German DNS TLS Server A+ ( USA Hosted In DEU ) - address_data: 159.69.198.101 tls_auth_name: "dot-de.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: YZeyeJf/suAR2fMHLc9RDPkcQi/e8EEnzk5Y1N90QQE= ## 10 - The BlahDNS Japan DNS TLS Server A+ ( JPN ) - address_data: 45.32.55.94 tls_auth_name: "dot-jp.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: oo7UO3PO7GhSEuOahGQRPpAcvdFUC7ZRDH3YpoGio4I= ## 11 - The BlahDNS Finland DNS TLS Server A+ ( FIN ) - address_data: 95.216.212.177 tls_auth_name: "dot-fi.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: PID8ufrN/lfloA6y/C+mpR8MT53GG6GkAd8k+RmgTwc= ## 12 - The dns.neutopia.org DNS TLS Server A+ ( FRA ) - address_data: 89.234.186.112 tls_auth_name: "dns.neutopia.org" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI= ## 13 - The dns.seby.io - Vultr DNS TLS Server A+ ( AUS ) - address_data: 45.76.113.31 tls_auth_name: "dot.seby.io" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: H13Su1659zEn0ZIblEShwjZO+M5gxKK2wXpVKQHgibM= ## 14 - The dns.seby.io - OVH DNS TLS Server A+ ( AUS ) - 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= ## 15 - The Foundation for Applied Privacy DNS TLS Server A+ ( AUT ) - address_data: 37.252.185.232 tls_auth_name: "dot1.appliedprivacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: w/3fNr64CFe2DQpbN3cRsGy2CgSRi51GsDwvcL4z8rg= ## 16 - The Secure DNS Project by PumpleX DNS TLS Server #1 A+ ( GBR ) - address_data: 51.38.83.141 tls_auth_name: "dns.oszx.co" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: TSy1ZYYNACIkGRWFAH0IoPJI4HHksmpST4ckZCb7MRY= ## 17 - The Digitale Gesellschaft DNS TLS Server #1 A+ ( CHE ) - address_data: 185.95.218.43 tls_auth_name: "dns.digitale-gesellschaft.ch" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: ZXYkM5saqxlSg6hM31XDJ62QlY89bSiPYFXaU3CmGoc= ## 18 - The Digitale Gesellschaft DNS TLS Server #2 A+ ( CHE ) - address_data: 185.95.218.42 tls_auth_name: "dns.digitale-gesellschaft.ch" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: YR0JbM0oGw6C/4iGjEuDONzBCc0qfLoWU3vGl/SzEUU= ## 19 - The Antoine Aflalo DNS TLS Server #1 A+ ( USA ) - address_data: 168.235.81.167 tls_auth_name: "dns-nyc.aaflalo.me" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 39DtR8cTs4rBfMnUxuAngI6XUc1HTeZVziSbSC56MIM= ## 20 - The Antoine Aflalo DNS TLS Server #2 A+ ( NLD ) - address_data: 176.56.236.175 tls_auth_name: "dns.aaflalo.me" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: cgtNzBzfLuhQ2DrFMoi55U1W+44KLJ2pU/UkqxS06Z8= ## 21 - The Privacy-First DNS TLS Server #1 A+ ( JPN ) - address_data: 172.104.93.80 tls_auth_name: "jp.tiar.app" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 5mweIYRkQwvITwGFbt+/zhcHFBdKjSwX4Vahut8nYgE= ## 22 - The Privacy-First DNS TLS Server #2 A+ ( SGP Hosted In USA ) - address_data: 174.138.29.175 tls_auth_name: "dot.tiar.app" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 5qmICfbLIMJkCngfDoIKd0QMXIPiyRuWamVPZUl9/vA= ## 23 - The ibuki.cgnat.net DNS TLS Server A+ ( USA ) - address_data: 35.198.2.76 tls_auth_name: "ibuki.cgnat.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Xgixyg7vSOO0jJQ/kWZE5/K6Z1HhrzPE2omwdpWD7cA= ## 24 - The PI-DNS.COM West USA DNS TLS Server A+ ( USA ) - address_data: 45.67.219.208 tls_auth_name: "dot.westus.pi-dns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: s2BoWwWBcEAy8iU2FXqNHUoPlQdp0fUtxaXf5irRHM4= ## 25 - The PI-DNS.COM DNS TLS East USA Server A+ ( USA ) - address_data: 185.213.26.187 tls_auth_name: "dot.eastus.pi-dns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: SEdkdZ3k+dmLWoD7HIWZ8b9CwXrctzHb94GpN405Gms= ## 26 - The PI-DNS.COM West Europe DNS TLS Server A+ ( NLD ) - address_data: 31.220.42.65 tls_auth_name: "dot.westeu.pi-dns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: bv7pN2V/E2ds5jhNiU9Qm/vgEkrhf7to2bTeX1R3m1g= ## 27 - The PI-DNS.COM North Europe DNS TLS Server A+ ( FIN ) - address_data: 95.216.181.228 tls_auth_name: "dot.northeu.pi-dns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: n3TS/j9J67vVc2aV0ADzT8E/Tup4P1+SghLtvDCZCJc= ## 28 - The Snopyta DNS TLS Server A+ ( FIN ) - address_data: 95.216.24.230 tls_auth_name: "fi.dot.dns.snopyta.org" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 4N75mKYSJ0hU7b2Ptmp2splcB4LAQHQqvWXPdJN7YtQ= ## 29 - The SecureDNS DNS TLS Server A+ ( NLD ) - address_data: 146.185.167.43 tls_auth_name: "ads-dot.securedns.eu" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g= ## 30 - The NixNet Uncensored Las Vegas DNS TLS Server A+ ( USA ) ## - or use ( tls_auth_name: "adblock.lv1.dns.nixnet.xyz" ) - address_data: 209.141.34.95 tls_auth_name: "uncensored.lv1.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: c+PSHI9qtGTOdmOJ+Npe6pEr/9Cr5SV9gj1bUOSeqfc= ## 31 - The NixNet Uncensored New York DNS TLS Server A+ ( USA ) ## - or use ( tls_auth_name: "adblock.ny1.dns.nixnet.xyz" ) - address_data: 199.195.251.84 tls_auth_name: "uncensored.ny1.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: tot6FUW7X/eSbZ/1JtX7jLB57zc9oWz+6YhreoFEwWI= ## 32 - The NixNet Uncensored Luxembourg DNS TLS Server A+ ( LUX ) ## - or use ( tls_auth_name: "adblock.lux1.dns.nixnet.xyz" ) - address_data: 104.244.78.231 tls_auth_name: "uncensored.lux1.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: bY/t7KxNzX0t+b8ve4m4UFWXvGsya7FGi86VfSSfOTo= ## 33 - The Lelux.fi DNS TLS Server A+ ( FRA Hosted In GBR ) - address_data: 51.158.147.50 tls_auth_name: "resolver-eu.lelux.fi" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /Gv53+cvMW9zvbIbw4bg0WSvKAnsUxCYsvUp1TaOSb0= ### Anycast DNS Privacy Public Resolvers ### ## 34 - The DNS.SB DNS TLS Server #1 A+ ( Anycast ) - address_data: 185.222.222.222 tls_auth_name: "dns.sb" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k= ## 35 - The DNS.SB DNS TLS Server #2 A+ ( Anycast ) - address_data: 185.184.222.222 tls_auth_name: "dns.sb" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k= ## 36 - The NixNet Uncensored Anycast DNS TLS Server A+ ( Anycast ) - address_data: 198.251.90.114 tls_auth_name: "uncensored.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: QEO37CPr6IgWZR+YE2XtzhTwP/7YW7/L8G9Ehc30wo8= ## 37 - The NixNet Adblock Anycast DNS TLS Server A+ ( Anycast ) - address_data: 198.251.90.89 tls_auth_name: "adblock.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: QEO37CPr6IgWZR+YE2XtzhTwP/7YW7/L8G9Ehc30wo8= ## 38 Quad9 'secure' service - Filters, does DNSSEC, ## doesn't send ECS ( Anycast ) ## ( NOTE: recommend reducing idle_timeout to 9000 if using Quad9 ) - address_data: 149.112.112.112 tls_auth_name: "dns.quad9.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /SlsviBkb05Y/8XiKF9+CZsgCtrqPQk5bh47o0R3/Cg= - address_data: 9.9.9.9 tls_auth_name: "dns.quad9.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /SlsviBkb05Y/8XiKF9+CZsgCtrqPQk5bh47o0R3/Cg= Save and Exit 5 - Configure Stubby To Implement TLSv1.3 For pfSense 2.5.0 Development Snapshots Add this entry ( found directly below ) to the bottom of your stubby.yml configuration file ( aka /usr/local/etc/stubby/stubby.yml ) - make sure to skip a line after last entry before appending these settings: # Set the acceptable ciphers for DNS over TLS. With OpenSSL 1.1.1 this list is # for TLS1.2 and older only. Ciphers for TLS1.3 should be set with the # tls_ciphersuites option. This option can also be given per upstream. # tls_cipher_list: "EECDH+AESGCM:EECDH+CHACHA20" # Set the acceptable cipher for DNS over TLS1.3. OpenSSL >= 1.1.1 is required # for this option. This option can also be given per upstream. tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256" # Set the minimum acceptable TLS version. Works with OpenSSL >= 1.1.1 only. # This option can also be given per upstream. tls_min_version: GETDNS_TLS1_3 # Set the maximum acceptable TLS version. Works with OpenSSL >= 1.1.1 only. # This option can also be given per upstream. # tls_max_version: GETDNS_TLS1_3 Starting with pfSense 2.5.0 Snapshots in order for TLSv1.3 protocol to work properly ( read at all ) in your Stubby instance, OpenSSL 1.1.1 must be active and configured in the kernel. pfSense 2.5.0 and above does provide OpenSSL 1.1.1 support. When you have OpenSSL 1.1.1 with TLSv1.3 support simply add the section above in order to set Stubby to implement TLS1.3. The operative lines necessary are these two specifically found at the bottom of the stubby.yml file above: tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256" tls_min_version: GETDNS_TLS1_3 See below for TLS1.3 Support Check SSH Commands - openssl s_client -connect 46.101.66.244:853 OR : openssl s_client -connect 45.32.55.94:443 Read Out Will Be Verified By These Lines Below: Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_CHACHA20_POLY1305_SHA256 OR : Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Depending on Configuration on Tested DOT Server Lastly, you can and should take advantage of this new DNS OVER TLS provider. You need to sign up and use configured settings in order to use it. NextDNS is a free service - ANYCAST and pretty much cutting edge. ANYCAST speeds up your DNS - Here it is: NextDNS https://my.nextdns.io/signup or feel free to use and test NextDNS " Try it now for free " Feature go to : https://nextdns.io/ 6- Now you must configure your Unbound DNS Server to use Stubby for DNS Over TLS. Go To Services > DNS Resolver > GENERAL SETTINGS UNDER DNS Resolver > GENERAL SETTINGS Network Interfaces = Select LAN ONLY ! # IF You Have Multiple Lan Interfaces - Select ALL LAN INTERFACES Under Custom options enter the following : server: forward-zone: name: "." # Allow all DNS queries forward-addr: [email protected] ## ( Your One Main LAN Address ) ## END OF ENTRY ## Note : do-not-query-localhost: no ## this entry is necessarily removed ## from this UNBOUND configuration ## Disabling DNS Queries From Localhost ( 127.0.0.1 ) Outgoing Network Interfaces = Select LAN ONLY ! # IF You Have Multiple Lan Interfaces - Select ALL LAN INTERFACES Make Sure to NOT CHECK - DO NOT CHECK - the box for DNS Query Forwarding. Save and Apply Settings Next -Under System > General Setup > DNS Server Settings Set the first DNS Server to Your One Main LAN Address ( 192.168.7.11 ) 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 - Disable DNS Forwarder Is Checked - I repeat - Is Checked ! - Save and Apply Settings 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. 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. 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 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. 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 Most Simple and Direct Method: gnutls-cli --print-cert -p 853 159.69.198.101 | grep "pin-sha256" | head -1 And / Or With Adjustment For SSL Port and Address Being Tested gnutls-cli --print-cert -p 443 159.69.198.101 | grep "pin-sha256" | head -1 - 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.
  7. My streaming IP was working fine till today. It completely cuts out my connection to the internet when I connect to it now. All other IP addresses on the service work fine including my Dedicated IP address. I have tried it in my iPad, iPhone and laptop computer (all the same). I have requested a new Streaming IP since I have paid for this service and it has stopped working. TorGuard support has been unable to help me, and has been ignoring my request. I have done all the steps they asked me to do and still the same. I will also contact my credit card company to request a refund for unmet services. If anybody else has similar issues with TorGuard, please let me know the outcome.
  8. LAN Interface For GETDNS and STUBBY Plus UNBOUND WHY YOU ASK ? ANSWER : IN LIFE ONE SHOULD HAVE OPTIONS IMPORTANT UPDATED INFORMATION !!! - READ FULL GUIDE BEFORE GETTING STARTED !!! Stop OpenWRT Router from occasionally allowing UNBOUND Root Hints to resolve queries on its own. This configuration ensures that localhost ( 127.0.0.1 ) will not be used as a resolver on OpenWRT Box. You will only use GETDNS and STUBBY DNS SERVERS if you follow this tutorial. You will use your One Main LAN Interface as the listening interface for STUBBY and the listening and outgoing interface for your UNBOUND DNS RESOLVER for OpenWRT. So, let's get started. See Below For Definition and Function Of Unbound Root Hints : Unbound is a caching DNS resolver. It uses a built in list of authoritative nameservers for the root zone (.), the so called root hints. On receiving a DNS query it will ask the root nameservers for an answer and will in almost all cases receive a delegation to a top level domain (TLD) authoritative nameserver. Source Document : https://man.openbsd.org/unbound 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). I was asked by a still skeptical devotee of DOH " What makes this way better than just running the DNS-over-https-proxy ? My answer was : Read this and make your decisions and conclusions concerning DOH vs DOT . Here is the article below : https://www.netmeister.org/blog/doh-dot-dnssec.html Short Synopsis of DOH: In other words , ( with DOH ) we gain the same protections as with DoT for our web applications, but leaves all other DNS traffic vulnerable. Subsequently, as a matter of fact and in practice with DNS OVER TLS ALL DNS traffic is invulnerable and protected.This is why I run DOT and eschew DOH on my OpenWRT Router. Further, Personally, I run GETDNS STUBBY and UNBOUND as described here along with ( wait for it ) FireFox DOH along with Encrypted SNI - plus TLS v 1.3 in Stubby and naturally a properly configured and encrypted VPN - Here is a basic guide as to how to do it - https://blog.grobox.de/2018/what-is-dns-privacy-and-how-to-set-it-up-for-openwrt/ however; a few modifications are necessary to run DOT as promised in the title of this tutorial As always - opkg update first and foremost Prerequisite You have a ca cert bundle installed on your router. You can do this by running the following opkg install ca-certificates 1 - opkg update ; opkg install unbound-daemon-heavy unbound-control unbound-control-setup luci-app-unbound unbound-anchor unbound-host unbound-checkconf odhcpd 2 - opkg update ; opkg install stubby getdns 3- My WORKING CONFIGS /etc/unbound/unbound_srv.conf ( Adjust For Your Router - I Run WRT1900ACS and WRT3200ACM So I Have Plenty Of Ram, Storage and 2 CPU's ) You should " Optimize Unbound " - especially increase size of cache among other things see guide here and adjust for your router's memory , number of cores and so on- see here: https://nlnetlabs.nl/documentation/unbound/howto-optimise/ ## Note : do-not-query-localhost: no ## this entry is necessarily removed ## from this UNBOUND configuration below ## Disabling DNS Queries From Localhost ( 127.0.0.1 ) cat >> /etc/unbound/unbound_srv.conf <<UNBOUND_SERVER_CONF server: tls-cert-bundle: "/var/lib/unbound/ca-certificates.crt" # use all CPUs num-threads: 2 # power of 2 close to num-threads msg-cache-slabs: 4 rrset-cache-slabs: 4 infra-cache-slabs: 4 key-cache-slabs: 4 # more cache memory, rrset=msg*2 rrset-cache-size: 200m msg-cache-size: 100m # more outgoing connections # depends on number of cores: 1024/cores - 50 outgoing-range: 8192 # Larger socket buffer. OS may need config. so-rcvbuf: 4m so-sndbuf: 4m interface: 192.168.7.11 # Put You One Main LAN Address Here outgoing-interface: 192.168.7.11 # Likewise Put You One Main LAN Address Here cache-min-ttl: 3600 cache-max-ttl: 86400 hide-identity: yes hide-version: yes hide-trustanchor: yes harden-glue: yes harden-dnssec-stripped: yes infra-cache-numhosts: 100000 num-queries-per-thread: 4096 max-udp-size: 3072 minimal-responses: yes rrset-roundrobin: yes use-caps-for-id: no do-ip6: no do-ip4: yes do-tcp: yes do-udp: yes prefetch: yes prefetch-key: yes qname-minimisation: yes qname-minimisation-strict: yes harden-below-nxdomain: yes aggressive-nsec: yes so-reuseport: yes unwanted-reply-threshold: 10000000 interface-automatic: yes verbosity: 1 private-domain: "your.domain" ## put your domain here harden-referral-path: yes target-fetch-policy: "0 0 0 0 0" val-clean-additional: yes ip-ratelimit: 300 ip-ratelimit-factor: 10 incoming-num-tcp: 100 edns-buffer-size: 4096 UNBOUND_SERVER_CONF As per guide :# Don’t let each server know the next recursion Enter via SSH command line: uci set '[email protected][0].query_minimize=1' uci commit I choose to use the /etc/stubby/stubby.yml file to configure STUBBY. My reasons for preferring to configure Stubby with the /etc/stubby/stubby.yml file instead of the now default UCI system /etc/config/stubby file are for several reasons. I found that I have more control over the security options which DNS OVER TLS is intended to provide. Like padding - 853 or 443 port and so on. So in order to use /etc/stubby/stubby.yml file, you must change a default setting in the /etc/config/stubby file to allow manual configuration. To keep this simple - go into default UCI STUBBY file which is /etc/config/stubby by entering nano /etc/config/stubby and then set option manual '1' - if you leave it at default setting of option manual 'o' you will not be able to use the /etc/stubby/stubby.yml file in order to configure STUBBY as before. So, after changing option manual '1' in the /etc/config/stubby file - configure /etc/stubby/stubby.yml as follows : 4 - 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 and Updated On February 17 2020 With A+ Rating - # 100% Perfecto Configuration on website: https://www.immuniweb.com/ssl/?id=Su8SeUQ4n # These servers support the most recent and secure TLS protocol version of TLS 1.3 ** # Good configuration - These server configurations support only # TLSv1.2 and TLSv1.3 protocols - current most secure encryption. # Also I have added the Country Locations of These DNS PRIVACY Servers # using the Alpha 3 Code Format # see country code lists here : # https://www.nationsonline.org/oneworld/country_code_list.htm and / or # https://www.iban.com/country-codes # Use as many or as few depending on your specific needs # Note: by default on OpenWRT stubby configuration is handled via # the UCI system and the file /etc/config/stubby. If you want to # use this file to configure stubby, then set "option manual '1'" # in /etc/config/stubby. resolution_type: GETDNS_RESOLUTION_STUB round_robin_upstreams: 1 appdata_dir: "/var/lib/stubby" tls_authentication: GETDNS_AUTHENTICATION_REQUIRED tls_query_padding_blocksize: 128 edns_client_subnet_private: 1 idle_timeout: 9000 - [email protected] # Put You One Main LAN Address Here dns_transport_list: - GETDNS_TRANSPORT_TLS tls_connection_retries: 5 tls_backoff_time: 900 timeout: 2000 tls_ca_path: "/etc/ssl/certs/" upstream_recursive_servers: ### IPV4 Servers ### ### DNS Privacy Test Servers ### ## 1 - The Surfnet/Sinodun DNS TLS Server #3 A+ ( NLD ) - address_data: 145.100.185.18 tls_port: 853 tls_auth_name: "dnsovertls3.sinodun.com" tls_pubkey_pinset: - digest: "sha256" value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8= ### Test servers ### ## 2 - The DNS Warden DNS TLS Server #1 A+ ( IND hosted in DEU ) - address_data: 116.203.70.156 tls_auth_name: "dot1.dnswarden.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: aPns02lcGrDxnJQcRSHN8Cfx0XG+IXwqy5ishTQtzR0= ## 3 - The DNS Warden DNS TLS Server #2 A+ ( IND hosted in DEU ) - address_data: 116.203.35.255 tls_auth_name: "dot2.dnswarden.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: aPns02lcGrDxnJQcRSHN8Cfx0XG+IXwqy5ishTQtzR0= ## 4 - The ContainerPI.com - CPI DNS TLS Server A+ ( JPN ) - address_data: 45.77.180.10 tls_auth_name: "dns.containerpi.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: xz8kGlumwEGkPwJ3QV/XlHRKCVNo2Fae8bM5YqlyvFs= ## 5 - The FEROZ SALAM DNS TLS Server A+ ( GBR ) - address_data: 46.101.66.244 tls_auth_name: "doh.li" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 0xvfP+YW1Ueh+CRKPxHRyPTK7HSMfgd1KvYAVwSZqbI= ## 6 - The Andrews & Arnold DNS TLS Server #1 A+ ( GBR ) - address_data: 217.169.20.23 tls_auth_name: "dns.aa.net.uk" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: QU5xobzrRJeiNVUXh0bpUO42Xwj1HQgZo/uA3Uztfhc= ## 7 - The Andrews & Arnold DNS TLS Server #2 A+ ( GBR ) - address_data: 217.169.20.22 tls_auth_name: "dns.aa.net.uk" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: SbMmQBuIp1HNX9FCCXuzHT0Nq4qnfwdwwH9i1/FYwT8= ## 8 - The dns.cmrg.net DNS TLS Server A+ ( CAN ) - address_data: 199.58.81.218 tls_auth_name: "dns.cmrg.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo= ## 9 - The BlahDNS German DNS TLS Server A+ ( USA Hosted In DEU ) - address_data: 159.69.198.101 tls_auth_name: "dot-de.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: YZeyeJf/suAR2fMHLc9RDPkcQi/e8EEnzk5Y1N90QQE= ## 10 - The BlahDNS Japan DNS TLS Server A+ ( JPN ) - address_data: 45.32.55.94 tls_auth_name: "dot-jp.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: oo7UO3PO7GhSEuOahGQRPpAcvdFUC7ZRDH3YpoGio4I= ## 11 - The BlahDNS Finland DNS TLS Server A+ ( FIN ) - address_data: 95.216.212.177 tls_auth_name: "dot-fi.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: PID8ufrN/lfloA6y/C+mpR8MT53GG6GkAd8k+RmgTwc= ## 12 - The dns.neutopia.org DNS TLS Server A+ ( FRA ) - address_data: 89.234.186.112 tls_auth_name: "dns.neutopia.org" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI= ## 13 - The dns.seby.io - Vultr DNS TLS Server A+ ( AUS ) - address_data: 45.76.113.31 tls_auth_name: "dot.seby.io" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: H13Su1659zEn0ZIblEShwjZO+M5gxKK2wXpVKQHgibM= ## 14 - The dns.seby.io - OVH DNS TLS Server A+ ( AUS ) - 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= ## 15 - The Foundation for Applied Privacy DNS TLS Server A+ ( AUT ) - address_data: 37.252.185.232 tls_auth_name: "dot1.appliedprivacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: w/3fNr64CFe2DQpbN3cRsGy2CgSRi51GsDwvcL4z8rg= ## 16 - The Secure DNS Project by PumpleX DNS TLS Server #1 A+ ( GBR ) - address_data: 51.38.83.141 tls_auth_name: "dns.oszx.co" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: TSy1ZYYNACIkGRWFAH0IoPJI4HHksmpST4ckZCb7MRY= ## 17 - The Digitale Gesellschaft DNS TLS Server #1 A+ ( CHE ) - address_data: 185.95.218.43 tls_auth_name: "dns.digitale-gesellschaft.ch" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: ZXYkM5saqxlSg6hM31XDJ62QlY89bSiPYFXaU3CmGoc= ## 18 - The Digitale Gesellschaft DNS TLS Server #2 A+ ( CHE ) - address_data: 185.95.218.42 tls_auth_name: "dns.digitale-gesellschaft.ch" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: YR0JbM0oGw6C/4iGjEuDONzBCc0qfLoWU3vGl/SzEUU= ## 19 - The Antoine Aflalo DNS TLS Server #1 A+ ( USA ) - address_data: 168.235.81.167 tls_auth_name: "dns-nyc.aaflalo.me" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 39DtR8cTs4rBfMnUxuAngI6XUc1HTeZVziSbSC56MIM= ## 20 - The Antoine Aflalo DNS TLS Server #2 A+ ( NLD ) - address_data: 176.56.236.175 tls_auth_name: "dns.aaflalo.me" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: cgtNzBzfLuhQ2DrFMoi55U1W+44KLJ2pU/UkqxS06Z8= ## 21 - The Privacy-First DNS TLS Server #1 A+ ( JPN ) - address_data: 172.104.93.80 tls_auth_name: "jp.tiar.app" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 5mweIYRkQwvITwGFbt+/zhcHFBdKjSwX4Vahut8nYgE= ## 22 - The Privacy-First DNS TLS Server #2 A+ ( SGP Hosted In USA ) - address_data: 174.138.29.175 tls_auth_name: "dot.tiar.app" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 5qmICfbLIMJkCngfDoIKd0QMXIPiyRuWamVPZUl9/vA= ## 23 - The ibuki.cgnat.net DNS TLS Server A+ ( USA ) - address_data: 35.198.2.76 tls_auth_name: "ibuki.cgnat.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Xgixyg7vSOO0jJQ/kWZE5/K6Z1HhrzPE2omwdpWD7cA= ## 24 - The PI-DNS.COM West USA DNS TLS Server A+ ( USA ) - address_data: 45.67.219.208 tls_auth_name: "dot.westus.pi-dns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: s2BoWwWBcEAy8iU2FXqNHUoPlQdp0fUtxaXf5irRHM4= ## 25 - The PI-DNS.COM DNS TLS East USA Server A+ ( USA ) - address_data: 185.213.26.187 tls_auth_name: "dot.eastus.pi-dns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: SEdkdZ3k+dmLWoD7HIWZ8b9CwXrctzHb94GpN405Gms= ## 26 - The PI-DNS.COM West Europe DNS TLS Server A+ ( NLD ) - address_data: 31.220.42.65 tls_auth_name: "dot.westeu.pi-dns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: bv7pN2V/E2ds5jhNiU9Qm/vgEkrhf7to2bTeX1R3m1g= ## 27 - The PI-DNS.COM North Europe DNS TLS Server A+ ( FIN ) - address_data: 95.216.181.228 tls_auth_name: "dot.northeu.pi-dns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: n3TS/j9J67vVc2aV0ADzT8E/Tup4P1+SghLtvDCZCJc= ## 28 - The Snopyta DNS TLS Server A+ ( FIN ) - address_data: 95.216.24.230 tls_auth_name: "fi.dot.dns.snopyta.org" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 4N75mKYSJ0hU7b2Ptmp2splcB4LAQHQqvWXPdJN7YtQ= ## 29 - The SecureDNS DNS TLS Server A+ ( NLD ) - address_data: 146.185.167.43 tls_auth_name: "ads-dot.securedns.eu" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g= ## 30 - The NixNet Uncensored Las Vegas DNS TLS Server A+ ( USA ) ## - or use ( tls_auth_name: "adblock.lv1.dns.nixnet.xyz" ) - address_data: 209.141.34.95 tls_auth_name: "uncensored.lv1.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: c+PSHI9qtGTOdmOJ+Npe6pEr/9Cr5SV9gj1bUOSeqfc= ## 31 - The NixNet Uncensored New York DNS TLS Server A+ ( USA ) ## - or use ( tls_auth_name: "adblock.ny1.dns.nixnet.xyz" ) - address_data: 199.195.251.84 tls_auth_name: "uncensored.ny1.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: tot6FUW7X/eSbZ/1JtX7jLB57zc9oWz+6YhreoFEwWI= ## 32 - The NixNet Uncensored Luxembourg DNS TLS Server A+ ( LUX ) ## - or use ( tls_auth_name: "adblock.lux1.dns.nixnet.xyz" ) - address_data: 104.244.78.231 tls_auth_name: "uncensored.lux1.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: bY/t7KxNzX0t+b8ve4m4UFWXvGsya7FGi86VfSSfOTo= ## 33 - The Lelux.fi DNS TLS Server A+ ( FRA Hosted In GBR ) - address_data: 51.158.147.50 tls_auth_name: "resolver-eu.lelux.fi" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /Gv53+cvMW9zvbIbw4bg0WSvKAnsUxCYsvUp1TaOSb0= ### Anycast DNS Privacy Public Resolvers ### ## 34 - The DNS.SB DNS TLS Server #1 A+ ( Anycast ) - address_data: 185.222.222.222 tls_auth_name: "dns.sb" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k= ## 35 - The DNS.SB DNS TLS Server #2 A+ ( Anycast ) - address_data: 185.184.222.222 tls_auth_name: "dns.sb" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k= ## 36 - The NixNet Uncensored Anycast DNS TLS Server A+ ( Anycast ) - address_data: 198.251.90.114 tls_auth_name: "uncensored.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: QEO37CPr6IgWZR+YE2XtzhTwP/7YW7/L8G9Ehc30wo8= ## 37 - The NixNet Adblock Anycast DNS TLS Server A+ ( Anycast ) - address_data: 198.251.90.89 tls_auth_name: "adblock.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: QEO37CPr6IgWZR+YE2XtzhTwP/7YW7/L8G9Ehc30wo8= ## 38 Quad9 'secure' service - Filters, does DNSSEC, ## doesn't send ECS ( Anycast ) ## ( NOTE: recommend reducing idle_timeout to 9000 if using Quad9 ) - address_data: 149.112.112.112 tls_auth_name: "dns.quad9.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /SlsviBkb05Y/8XiKF9+CZsgCtrqPQk5bh47o0R3/Cg= - address_data: 9.9.9.9 tls_auth_name: "dns.quad9.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /SlsviBkb05Y/8XiKF9+CZsgCtrqPQk5bh47o0R3/Cg= # Set the acceptable ciphers for DNS over TLS. With OpenSSL 1.1.1 this list is # for TLS1.2 and older only. Ciphers for TLS1.3 should be set with the # tls_ciphersuites option. This option can also be given per upstream. # tls_cipher_list: "EECDH+AESGCM:EECDH+CHACHA20" # Set the acceptable cipher for DNS over TLS1.3. OpenSSL >= 1.1.1 is required # for this option. This option can also be given per upstream. tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256" # Set the minimum acceptable TLS version. Works with OpenSSL >= 1.1.1 only. # This option can also be given per upstream. tls_min_version: GETDNS_TLS1_3 # Set the maximum acceptable TLS version. Works with OpenSSL >= 1.1.1 only. # This option can also be given per upstream. # tls_max_version: GETDNS_TLS1_3 In order for TLSv1.3 protocol to work properly ( read at all ) in your Stubby instance, OpenWrt must have OpenSSL 1.1.1 active and configured in the kernel. Any OpenWrt 18.06 Build does not offer OpenSSL 1.1.1 in any shape, form or fashion.OpenWrt 19.07.0 Release Candidates and Snapshots do provide OpenSSL 1.1.1 support. Once you have OpenSSL 1.1.1 with TLSv1.3 simply follow the guide above in order to set Stubby to implement TLS1.3. The operative lines necessary are these two specifically found at the bottom of the stubby.yml file above: tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256" tls_min_version: GETDNS_TLS1_3 See below for TLS1.3 Support Check SSH Commands - openssl s_client 168.235.81.167:853 OR : openssl s_client 159.69.198.101:443 Read Out Will Be Verified By These Lines Below: Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_CHACHA20_POLY1305_SHA256 OR : Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Depending on Configuration on Tested DOT Server 5 - MY WORKING CONFIG /etc/unbound/unbound_ext.conf ( Simply Copy and Paste Into Your SSH Session and Hit Enter ) cat >> /etc/unbound/unbound_ext.conf <<UNBOUND_FORWARD_CONF forward-zone: name: "." # Allow all DNS queries forward-addr: [email protected] # Forward Unbound To Stubby Address/Port UNBOUND_FORWARD_CONF 6 - # Move dnsmasq to port 53535 where it will still serve local DNS from DHCP # Network -> DHCP & DNS -> Advanced Settings -> DNS server port to 53535 uci set '[email protected][0].port=53535' # Configure dnsmasq to send a DNS Server DHCP option with its LAN IP # since it does not do this by default when port is configured. uci add_list "dhcp.lan.dhcp_option=option:dns-server,$(uci get network.lan.ipaddr)" uci set '[email protected][0].dhcp_link=dnsmasq' # Save & Apply (will restart dnsmasq, DNS unreachable until unbound is up) uci commit && reload_config # Restart (or start) unbound (System -> Startup -> unbound -> Restart) /etc/init.d/unbound restart 7 - uci add_list [email protected][-1].server='192.168.7.11#5453' # Put You One Main LAN Address Here uci set [email protected][-1].noresolv=1 uci commit && reload_config A - Via UCI (Unified Configuration Interface) - in shell uci set [email protected][0].cachesize=8192 uci set [email protected][0].dnsforwardmax=250 uci set [email protected][0].rebind_protection=1 uci set [email protected][0].ednspacket_max=4096 uci commit dhcp && reload_config 8 - nano /etc/config/network uci set network.wan.peerdns='0' uci set network.wan.dns='192.168.7.11' uci commit && reload_config 9 - nano /etc/config/unbound # Edit Unbound Config File config unbound option add_extra_dns '0' option add_local_fqdn '1' option add_wan_fqdn '0' option dhcp4_slaac6 '0' option dns64 '0' option dns64_prefix '64:ff9b::/96' option domain "your.domain" ## put your domain here option domain_type 'transparent' option edns_size '4096' option extended_stats '1' option hide_binddata '1' option extended_luci '1' option luci_expanded '1' option listen_port '53' option localservice '1' option num_threads '2' option manual_conf '0' option protocol 'ip4_only' option query_minimize '1' option query_min_strict '1' option rebind_localhost '1' option rebind_protection '1' option recursion 'aggressive' option resource 'medium' option root_age '9' option ttl_min '150' option unbound_control '3' option validator '1' option validator_ntp '1' option verbosity '2' list trigger_interface 'wan' list trigger_interface 'lan' list domain_insecure '3.us.pool.ntp.org' option dhcp_link 'dnsmasq' 10 - Final Step --- # /etc/init.d/unbound restart 11 - # reboot & exit 12 - Install OpenWRT dnsmasq-full package # opkg update ; opkg install dnsmasq-full --download-only && opkg remove dnsmasq && opkg install dnsmasq-full --cache . && rm *.ipk Done - See https://forums.torguard.net/index.php?/topic/1374-from-the-dns-privacy-project-dns-over-tls-on-openwrtlede-featuring-unbound-getdns-and-stubby/ or ( From The DNS Privacy Project ) https://forum.openwrt.org/t/from-the-dns-privacy-project-dns-over-tls-on-openwrt-lede-featuring-unbound-getdns-and-stubby/13765 For Comparisons - Peace
  9. LAN Interface For GETDNS and STUBBY Plus UNBOUND WHY YOU ASK ? ANSWER : IN LIFE ONE SHOULD HAVE OPTIONS IMPORTANT UPDATED INFORMATION !!! - READ FULL GUIDE BEFORE GETTING STARTED !!! Stop OPNsense Router from occasionally allowing UNBOUND Root Hints to resolve queries on its own. This configuration ensures that localhost ( 127.0.0.1 ) will not be used as a resolver on OPNsense Box. You will only use GETDNS and STUBBY DNS SERVERS if you follow this tutorial. You will use your One Main LAN Interface as the listening interface for STUBBY and the listening and outgoing interface for your UNBOUND DNS RESOLVER on OPNsense. So, let's get started. See Below For Definition and Function Of Unbound Root Hints : Unbound is a caching DNS resolver. It uses a built in list of authoritative nameservers for the root zone (.), the so called root hints. On receiving a DNS query it will ask the root nameservers for an answer and will in almost all cases receive a delegation to a top level domain (TLD) authoritative nameserver. Source Document : https://man.openbsd.org/unbound First you all know the drill by now - " The Intro " we would all have a better world if we remember to practice the concept that - NOW ! is the time for all of US ( A ) to GET UP & GET INVLOVED and act with SOUL POWER ! - lyrics to sing along : https://genius.com/James-brown-get-up-get-into-it-get-involved-lyrics plus https://genius.com/James-brown-soul-power-lyrics and video : https://www.youtube.com/watch?v=1pvIarW3xHg Bonus JB : https://www.youtube.com/watch?v=v8TvBPshngE - 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). I was asked by a still skeptical devotee of DOH " What makes this way better than just running the DNS-over-https-proxy ? My answer was : Read this and make your decisions and conclusions concerning DOH vs DOT . Here is the article below : https://www.netmeister.org/blog/doh-dot-dnssec.html Short Synopsis of DOH: In other words , ( with DOH ) we gain the same protections as with DoT for our web applications, but leaves all other DNS traffic vulnerable. Subsequently, as a matter of fact and in practice with DNS OVER TLS ALL DNS traffic is invulnerable and protected.This is why I run DOT and eschew DOH on my OPNsense Router. Further, Personally, I run GETDNS STUBBY and UNBOUND as described here along with ( wait for it ) FireFox DOH along with Encrypted SNI - plus TLS v 1.3 in Stubby and naturally a properly configured and encrypted VPN - 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 go 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 and Updated On February 17 2020 With A+ Rating - 100% Perfecto Configuration on website: https://www.immuniweb.com/ssl/?id=Su8SeUQ4n ** These servers support the most recent and secure TLS protocol version of TLS 1.3 ** Good configuration - These server configurations support only TLSv1.2 and TLSv1.3 protocols - current most secure encryption. # Also I have added the Country Locations of These DNS PRIVACY Servers using the Alpha 3 Code Format # see country code lists here : # https://www.nationsonline.org/oneworld/country_code_list.htm or https://www.iban.com/country-codes # Use as many or as few depending on your specific needs ## Go Into SSH shell and enter : # 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: 9000 listen_addresses: - [email protected] ## Enter Your One Main LAN Address Here 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 ### ## 1 - The Surfnet/Sinodun DNS TLS Server #3 A+ ( NLD ) - address_data: 145.100.185.18 tls_port: 853 tls_auth_name: "dnsovertls3.sinodun.com" tls_pubkey_pinset: - digest: "sha256" value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8= ### Test servers ### ## 2 - The DNS Warden DNS TLS Server #1 A+ ( IND hosted in DEU ) - address_data: 116.203.70.156 tls_auth_name: "dot1.dnswarden.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: aPns02lcGrDxnJQcRSHN8Cfx0XG+IXwqy5ishTQtzR0= ## 3 - The DNS Warden DNS TLS Server #2 A+ ( IND hosted in DEU ) - address_data: 116.203.35.255 tls_auth_name: "dot2.dnswarden.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: aPns02lcGrDxnJQcRSHN8Cfx0XG+IXwqy5ishTQtzR0= ## 4 - The ContainerPI.com - CPI DNS TLS Server A+ ( JPN ) - address_data: 45.77.180.10 tls_auth_name: "dns.containerpi.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: xz8kGlumwEGkPwJ3QV/XlHRKCVNo2Fae8bM5YqlyvFs= ## 5 - The FEROZ SALAM DNS TLS Server A+ ( GBR ) - address_data: 46.101.66.244 tls_auth_name: "doh.li" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 0xvfP+YW1Ueh+CRKPxHRyPTK7HSMfgd1KvYAVwSZqbI= ## 6 - The Andrews & Arnold DNS TLS Server #1 A+ ( GBR ) - address_data: 217.169.20.23 tls_auth_name: "dns.aa.net.uk" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: QU5xobzrRJeiNVUXh0bpUO42Xwj1HQgZo/uA3Uztfhc= ## 7 - The Andrews & Arnold DNS TLS Server #2 A+ ( GBR ) - address_data: 217.169.20.22 tls_auth_name: "dns.aa.net.uk" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: SbMmQBuIp1HNX9FCCXuzHT0Nq4qnfwdwwH9i1/FYwT8= ## 8 - The dns.cmrg.net DNS TLS Server A+ ( CAN ) - address_data: 199.58.81.218 tls_auth_name: "dns.cmrg.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo= ## 9 - The BlahDNS German DNS TLS Server A+ ( USA Hosted In DEU ) - address_data: 159.69.198.101 tls_auth_name: "dot-de.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: YZeyeJf/suAR2fMHLc9RDPkcQi/e8EEnzk5Y1N90QQE= ## 10 - The BlahDNS Japan DNS TLS Server A+ ( JPN ) - address_data: 45.32.55.94 tls_auth_name: "dot-jp.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: oo7UO3PO7GhSEuOahGQRPpAcvdFUC7ZRDH3YpoGio4I= ## 11 - The BlahDNS Finland DNS TLS Server A+ ( FIN ) - address_data: 95.216.212.177 tls_auth_name: "dot-fi.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: PID8ufrN/lfloA6y/C+mpR8MT53GG6GkAd8k+RmgTwc= ## 12 - The dns.neutopia.org DNS TLS Server A+ ( FRA ) - address_data: 89.234.186.112 tls_auth_name: "dns.neutopia.org" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI= ## 13 - The dns.seby.io - Vultr DNS TLS Server A+ ( AUS ) - address_data: 45.76.113.31 tls_auth_name: "dot.seby.io" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: H13Su1659zEn0ZIblEShwjZO+M5gxKK2wXpVKQHgibM= ## 14 - The dns.seby.io - OVH DNS TLS Server A+ ( AUS ) - 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= ## 15 - The Foundation for Applied Privacy DNS TLS Server A+ ( AUT ) - address_data: 37.252.185.232 tls_auth_name: "dot1.appliedprivacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: w/3fNr64CFe2DQpbN3cRsGy2CgSRi51GsDwvcL4z8rg= ## 16 - The Secure DNS Project by PumpleX DNS TLS Server #1 A+ ( GBR ) - address_data: 51.38.83.141 tls_auth_name: "dns.oszx.co" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: TSy1ZYYNACIkGRWFAH0IoPJI4HHksmpST4ckZCb7MRY= ## 17 - The Digitale Gesellschaft DNS TLS Server #1 A+ ( CHE ) - address_data: 185.95.218.43 tls_auth_name: "dns.digitale-gesellschaft.ch" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: ZXYkM5saqxlSg6hM31XDJ62QlY89bSiPYFXaU3CmGoc= ## 18 - The Digitale Gesellschaft DNS TLS Server #2 A+ ( CHE ) - address_data: 185.95.218.42 tls_auth_name: "dns.digitale-gesellschaft.ch" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: YR0JbM0oGw6C/4iGjEuDONzBCc0qfLoWU3vGl/SzEUU= ## 19 - The Antoine Aflalo DNS TLS Server #1 A+ ( USA ) - address_data: 168.235.81.167 tls_auth_name: "dns-nyc.aaflalo.me" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 39DtR8cTs4rBfMnUxuAngI6XUc1HTeZVziSbSC56MIM= ## 20 - The Antoine Aflalo DNS TLS Server #2 A+ ( NLD ) - address_data: 176.56.236.175 tls_auth_name: "dns.aaflalo.me" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: cgtNzBzfLuhQ2DrFMoi55U1W+44KLJ2pU/UkqxS06Z8= ## 21 - The Privacy-First DNS TLS Server #1 A+ ( JPN ) - address_data: 172.104.93.80 tls_auth_name: "jp.tiar.app" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 5mweIYRkQwvITwGFbt+/zhcHFBdKjSwX4Vahut8nYgE= ## 22 - The Privacy-First DNS TLS Server #2 A+ ( SGP Hosted In USA ) - address_data: 174.138.29.175 tls_auth_name: "dot.tiar.app" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 5qmICfbLIMJkCngfDoIKd0QMXIPiyRuWamVPZUl9/vA= ## 23 - The ibuki.cgnat.net DNS TLS Server A+ ( USA ) - address_data: 35.198.2.76 tls_auth_name: "ibuki.cgnat.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Xgixyg7vSOO0jJQ/kWZE5/K6Z1HhrzPE2omwdpWD7cA= ## 24 - The PI-DNS.COM West USA DNS TLS Server A+ ( USA ) - address_data: 45.67.219.208 tls_auth_name: "dot.westus.pi-dns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: s2BoWwWBcEAy8iU2FXqNHUoPlQdp0fUtxaXf5irRHM4= ## 25 - The PI-DNS.COM DNS TLS East USA Server A+ ( USA ) - address_data: 185.213.26.187 tls_auth_name: "dot.eastus.pi-dns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: SEdkdZ3k+dmLWoD7HIWZ8b9CwXrctzHb94GpN405Gms= ## 26 - The PI-DNS.COM West Europe DNS TLS Server A+ ( NLD ) - address_data: 31.220.42.65 tls_auth_name: "dot.westeu.pi-dns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: bv7pN2V/E2ds5jhNiU9Qm/vgEkrhf7to2bTeX1R3m1g= ## 27 - The PI-DNS.COM North Europe DNS TLS Server A+ ( FIN ) - address_data: 95.216.181.228 tls_auth_name: "dot.northeu.pi-dns.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: n3TS/j9J67vVc2aV0ADzT8E/Tup4P1+SghLtvDCZCJc= ## 28 - The Snopyta DNS TLS Server A+ ( FIN ) - address_data: 95.216.24.230 tls_auth_name: "fi.dot.dns.snopyta.org" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 4N75mKYSJ0hU7b2Ptmp2splcB4LAQHQqvWXPdJN7YtQ= ## 29 - The SecureDNS DNS TLS Server A+ ( NLD ) - address_data: 146.185.167.43 tls_auth_name: "ads-dot.securedns.eu" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g= ## 30 - The NixNet Uncensored Las Vegas DNS TLS Server A+ ( USA ) ## - or use ( tls_auth_name: "adblock.lv1.dns.nixnet.xyz" ) - address_data: 209.141.34.95 tls_auth_name: "uncensored.lv1.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: c+PSHI9qtGTOdmOJ+Npe6pEr/9Cr5SV9gj1bUOSeqfc= ## 31 - The NixNet Uncensored New York DNS TLS Server A+ ( USA ) ## - or use ( tls_auth_name: "adblock.ny1.dns.nixnet.xyz" ) - address_data: 199.195.251.84 tls_auth_name: "uncensored.ny1.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: tot6FUW7X/eSbZ/1JtX7jLB57zc9oWz+6YhreoFEwWI= ## 32 - The NixNet Uncensored Luxembourg DNS TLS Server A+ ( LUX ) ## - or use ( tls_auth_name: "adblock.lux1.dns.nixnet.xyz" ) - address_data: 104.244.78.231 tls_auth_name: "uncensored.lux1.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: bY/t7KxNzX0t+b8ve4m4UFWXvGsya7FGi86VfSSfOTo= ## 33 - The Lelux.fi DNS TLS Server A+ ( FRA Hosted In GBR ) - address_data: 51.158.147.50 tls_auth_name: "resolver-eu.lelux.fi" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /Gv53+cvMW9zvbIbw4bg0WSvKAnsUxCYsvUp1TaOSb0= ### Anycast DNS Privacy Public Resolvers ### ## 34 - The DNS.SB DNS TLS Server #1 A+ ( Anycast ) - address_data: 185.222.222.222 tls_auth_name: "dns.sb" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k= ## 35 - The DNS.SB DNS TLS Server #2 A+ ( Anycast ) - address_data: 185.184.222.222 tls_auth_name: "dns.sb" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k= ## 36 - The NixNet Uncensored Anycast DNS TLS Server A+ ( Anycast ) - address_data: 198.251.90.114 tls_auth_name: "uncensored.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: QEO37CPr6IgWZR+YE2XtzhTwP/7YW7/L8G9Ehc30wo8= ## 37 - The NixNet Adblock Anycast DNS TLS Server A+ ( Anycast ) - address_data: 198.251.90.89 tls_auth_name: "adblock.any.dns.nixnet.xyz" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: QEO37CPr6IgWZR+YE2XtzhTwP/7YW7/L8G9Ehc30wo8= ## 38 Quad9 'secure' service - Filters, does DNSSEC, ## doesn't send ECS ( Anycast ) ## ( NOTE: recommend reducing idle_timeout to 9000 if using Quad9 ) - address_data: 149.112.112.112 tls_auth_name: "dns.quad9.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /SlsviBkb05Y/8XiKF9+CZsgCtrqPQk5bh47o0R3/Cg= - address_data: 9.9.9.9 tls_auth_name: "dns.quad9.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /SlsviBkb05Y/8XiKF9+CZsgCtrqPQk5bh47o0R3/Cg= Save and Exit Configure Stubby To Implement TLSv1.3 For OPNsense 20.1 And Above Add this entry ( found directly below ) to the bottom of your stubby.yml configuration file ( aka /usr/local/etc/stubby/stubby.yml ) - make sure to skip a line after last entry before appending these settings: # Set the acceptable ciphers for DNS over TLS. With OpenSSL 1.1.1 this list is # for TLS1.2 and older only. Ciphers for TLS1.3 should be set with the # tls_ciphersuites option. This option can also be given per upstream. # tls_cipher_list: "EECDH+AESGCM:EECDH+CHACHA20" # Set the acceptable cipher for DNS over TLS1.3. OpenSSL >= 1.1.1 is required # for this option. This option can also be given per upstream. tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256" # Set the minimum acceptable TLS version. Works with OpenSSL >= 1.1.1 only. # This option can also be given per upstream. tls_min_version: GETDNS_TLS1_3 # Set the maximum acceptable TLS version. Works with OpenSSL >= 1.1.1 only. # This option can also be given per upstream. # tls_max_version: GETDNS_TLS1_3 Starting with OPNsense 20.1-RC1 in order for TLSv1.3 protocol to work properly ( read at all ) in your Stubby instance, OpenSSL 1.1.1 must be active and configured in the kernel. OPNsense 20.1-RC1 and above does provide OpenSSL 1.1.1 support. When you have OpenSSL 1.1.1 with TLSv1.3 support simply add the section above in order to set Stubby to implement TLS1.3. The operative lines necessary are these two specifically found at the bottom of the stubby.yml file above: tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256" tls_min_version: GETDNS_TLS1_3 See below for TLS1.3 Support Check SSH Commands - openssl s_client -connect 46.101.66.244:853 OR : openssl s_client -connect 45.32.55.94:443 Read Out Will Be Verified By These Lines Below: Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_CHACHA20_POLY1305_SHA256 OR : Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Depending on Configuration on Tested DOT Server Lastly, you can and should take advantage of this new DNS OVER TLS provider. You need to sign up and use configured settings in order to use it. NextDNS is a free service - ANYCAST and pretty much cutting edge. ANYCAST speeds up your DNS - Here it is: NextDNS https://my.nextdns.io/signup or feel free to use and test NextDNS " Try it now for free " Feature go to : https://nextdns.io/ 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 : # touch /etc/rc.conf.d/stubby - create the needed new file # 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. Go To Services > UNBOUND > GENERAL SETTINGS UNDER UNBOUND GENERAL SETTINGS Network Interfaces = Select LAN ONLY ! # IF You Have Multiple Lan Interfaces - Select ALL LAN INTERFACES Under Custom options enter the following : server: forward-zone: name: "." # Allow all DNS queries forward-addr: [email protected] ## ( Your One Main LAN Address ) ## END OF ENTRY ## Note : do-not-query-localhost: no ## this entry is necessarily removed ## from this UNBOUND configuration ## Disabling DNS Queries From Localhost ( 127.0.0.1 ) Outgoing Network Interfaces = Select LAN ONLY ! # IF You Have Multiple Lan Interfaces - Select ALL LAN INTERFACES 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 Your One Main LAN Address ( 192.168.7.11 ) 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 Checked - I repeat - Is Checked ! - 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. 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 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. 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 Most Simple and Direct Method: gnutls-cli --print-cert -p 853 159.69.198.101 | grep "pin-sha256" | head -1 And / Or With Adjustment For SSL Port and Address Being Tested gnutls-cli --print-cert -p 443 159.69.198.101 | grep "pin-sha256" | head -1 - 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.
  10. Last week
  11. Hi, I've followed the FAQs and guides for setting up a port forward. Ive tried it with OpenVPN, open connect changing the port number changing the Cipher from AES-128-CBC, AES-256-CBC, non-encrypted changing from TCP to UDP connection Everything that i've tried shows that the port is open through the manage your port fowarding, but when I try a test (https://www.yougetsignal.com/tools/open-ports/) the port is not open. I've checked my firewalls and disabled all windows firewalls for both public and private connections. I don't know what else to do to get the port open and working. Any ideas?
  12. Support

    TorGuard Chrome VPN Extension 1.3.8

    Please open a support ticket, im not able to reproduce, a login error message is normally always something blocking the connecting port or simply wrong credentials.
  13. Support

    Torguard Bricks my Connection

    Hi, when you say it bricks your connection do you mean when you connect you have no connectivity? or the app stops responding? Can you go to more settings --> network tab --> uncheck the seamless reconnect option and let us know if this works. Do you have any AV software? Regards
  14. I tried starting a VPN connection right after I purchased it and it stopped responding. When it stops responding I can't connect to anything, then need to restart my computer. As long as I don't touch TorGuard my internet works fine, but when I open it it bricks my entire connection and need to restart. Please help, I can't exactly just waste $30
  15. Newguy2020

    TorGuard Chrome VPN Extension 1.3.8

    I have verified my user/password and they work to login both the website and windows client. I am only using windows defender for AV at the moment. Firewall rules are default.
  16. Hey all, first post here. I was wondering if I could setup almost a LAN Bypass, similar to what is available on android devices, so I can connect to the VPN app for everything except connection to my Chromecast device. The issue is I cannot connect to my Chromecast device while on a different IP address through the VPN. Perhaps there is another solution I am not seeing, but right now I am thinking setting up some kind of exception would be best. Thanks for the help! Details: Windows 10 Desktop Chromecast Ultra Torguard Windows App
  17. jackmeat

    Desktop Restricted Apps

    I actually have the same question. Was just looking for this tonight but on the windows client. Seems easy as heck to find on the android client but certainly not so in the desktop client.
  18. uNc

    Torguard Ikev2 vpn configuration

    Changed DNS numerous times, no effect. Most asian secureconnect locations return UAF error (User Authentication Failed), some server locations accept my login credentials but many do not. Too many problems/headaches with torguards IKEv2 on MacOS. Time to move on from TG IKEv2 at this point, to one that performs as designed and is fit for purpose.
  19. Hi - how recently did you start experiencing these pings?
  20. Support

    Getting Cipher Not Supported

    Hi - what version of Tg client are you running there?
  21. Support

    Torguard Ikev2 vpn configuration

    I would suggest you change the DNS server for your IKev2 connection under advanced and see if this makes any difference, it could be a cause for slow speeds.
  22. Support

    Torguard Ikev2 vpn configuration

    Are you being deliberately obtuse? please care to read my reply before you "spout off" - I clearly told you to connect to IKEv2, NOTE down the IP (as in copy it to a text file) then add it to the TorGuard Client under more settings --> Servers tab.
  23. uNc

    Torguard Ikev2 vpn configuration

    Torguard IKEv2 IP (Singapore): 159.65.14.68 Torguard OpenVPN IP (Singapore) UDP Port 995 /desktop App : 185.200.117.142 Those are two very different IP address's. U need to get your facts straight before spouttin off!
  24. Support

    Torguard Ikev2 vpn configuration

    FYI this was already coming - but in regards to IKEv2, on different providers - maybe some other providers sacrifice security for speed? you wouldn't know any better! And to prove your point, connect to IKEv2, note down the IP, then connect to it via openvpn.
  25. uNc

    Torguard Ikev2 vpn configuration

    Whatever, your IKEv2 sucks, the OpenVPN and IKEv2 are on the same network, but IKEv2 speed is terrible....tells me the problem is definatelty a Torguard issue. without any proof to the contrary, you should find a solution. Update your desktop app to use IKEv2!
  26. Support

    Torguard Ikev2 vpn configuration

    OpenVPN is on the exact same servers/network so if the problem was our network then OpenVPN would be affected as well!
  1. Load more activity
×
×
  • Create New...