Jump to content
TorGuard

Leaderboard

  1. Support

    Support

    Administrators


    • Points

      9

    • Content Count

      2,176


  2. RyDze

    RyDze

    Members


    • Points

      3

    • Content Count

      14


  3. kurisu

    kurisu

    Members


    • Points

      3

    • Content Count

      23


  4. 117211_1511348143

    117211_1511348143

    Members


    • Points

      3

    • Content Count

      13



Popular Content

Showing content with the highest reputation since 11/14/2018 in all areas

  1. 1 point
    Good day. I guess this a Feature Request? I think the port-reservation website should let us pick a "pool" (a city) and then suggest a server automatically; even better if it looks at which port we want and then picks a server that doesn't have that port already reserved.Here is why I'd like this: When you connect to a "pool" the VPN client picks a server randomly from that pool. This means that on average, every server in the pool will have the same load - the same number of users using it. However, if 1000 people have reserved ports on Server A, then we can expect that particular server to have, on a bad day, 1000 more people using it, since TorGuard graciously lets us pick which server we connect to (you can "pin" a server in the client, or even multiple ones if you want.) So if I were to want to pick a server for my own port forwards, I'd want the server with the least amount of people already reserving ports on it Because that particular server should be the one with the least load, on average. As it is, I can't really pick any server over any another in the same pool, since they all ping about the same - I can't tell which has the least load. This should also benefit TorGuard, helping to distribute load across servers more evenly. Regards,
  2. 1 point
    Application specific option. Apparently this was in development....
  3. 1 point
    Yes but didnt get anywhere however after extensive troubleshooting, this is a digital signature issue with ver 1809 of Windows 10, I went back to 1803 and its OK
  4. 1 point
    I would suggest you open a support ticket here https://torguard.net/submitticket.php and explain your problem. Thanks
  5. 1 point
    Hi, Please try using different ports switching between TCP and UDP, if that fails, enable stealth proxy under Settings and recheck to see if that connects. Regards
  6. 1 point
    UPDATE!!! It's the TAP adapter. By default client installs 9.21 tap adapter. I tried the 9.9 version offered in setup and no issues. I don't know why 9.21 is default on Win 7 x64, but it really introduces bad latency when having multiple streams.
  7. 1 point
    support answer was "To be honest, there's nothing to fix here, a WAIT status doesn't indicate a problem with the client, it normally means for some reason you cannot reach the server to connect or your ISP regularly filters UDP on specific ports - does this happen with all servers/ports or just the one?" If it does happen to you then try to use other ports, i will keep in touch with support if its happening again in the future.
  8. 1 point
    Interim further testing indicates you need to connect to your chosen VPN server on port 1912 for port forwarding to work - despite being able to choose from all connecting ports (1194, 1195 etc) for establishing your VPN on the port forwarding setup form. Obviously you can choose any unused port to forward. Don't forget you'll likely need to forward the same port as both TCP and UDP for torrenting.
  9. 1 point
    Archive.is not loading is due to the site administrator's hardline policy on how some DNS servers work (or do not, according to him). CloudFlare appears to be the default choice for TG VPN users, and it is incompatible with how archive.today (aka archive.li/archive.is etc) operates their DNS. From the admin: "unlike other public DNS services, 1.1.1.1 does not support EDNS Client Subnet." The site will simply fail to load for any CloudFlare DNS users. CloudFlare support thread about this problem: https://community.cloudflare.com/t/archive-is-error-1001/18227/12 I would try setting your DNS to Google DNS. Also FWIW, archive.is admin is also recommending to stop using archive.is and use archive.today or one of his other domains instead.
  10. 1 point
    I had some issues earlier but support live chat helped me out. The app installed with some default settings which may not be optimal for port forwarding, not sure. Support recommended these changes: I was already connecting with OpenVPN over UDP but with a stronger cipher and a different port. I didn't modify my TorGuard DNS settings (just using DHCP and VPN-pushed once connected, instead of Google for everything). I did however uncheck 'Seamless Reconnect' (what does that do?) and I also checked WebRTC Leak Prevent. IPv6 Leak Prevent was already checked. I'd already added my desired VPN IP as a custom server in the TG app preferences, be sure to do that. If you want to test, you can connect to a country server and 'pin' its IP (click the pushpin next to the public IP once connected, then use that for your port forward request - set up a custom server if all works after a reconnect.) I also deleted and remade my port forward request in the control panel. Mine was a combined TCP and UDP one, I remade it for port 1912 on my chosen VPN IP. I'd already tried port 1194 and 1195 without success. Not entirely sure what made it work in the end - I should do more testing in future to figure it out. I guess support recommend I use a simpler cipher to avoid any session setup problems, I wouldn't have thought that would make a difference. I would be interested to see if port forwards only work if they are requested, and you connect, via port 1912.
  11. 1 point
    Hello, OpenDNS does keep logs of the sites you visit, we don't so i would recommend you use TG public DNS or endpoint DNS if you can. In regards to captcha's on our own IP's, we can't exactly whitelist any Vpn IP's of which thousands of users will be using, if we whitelist them then we effectively let potential hackers do as they please on the site, brute force, dos etc unchecked. We also have to protect ourselves... Regards
  12. 1 point
    Hi JessiTom, you are right, normally that would be the case. The problem is that OpenVPN encryption is single threaded i.e. can use only one CPU core, no matter what. This is also the reason why OpenVPN on routers was/is relatively slow --> CPU is the bottleneck. What merlin does (among other things) is using the routers CPU core 2 to maintain all "normal" router functions like firewall, routing, MAC access etc etc and core 1 will focus on encryption. This way you get the max bandwidth (encryption wise) out of your router. Otherwise all would be balanced (as you already mentioned). But mind you, using core 1 solely for encryption works only with merlin firmware (as far as i know) so you need to use an ASUS router. And when you are at it choose the 86U (strongest CPU in the consumer market right now). I have seen some speedtests with the 86U and merlin firmware (under optimal environment) that could reach and breach 200MBit encrypted transfer! And thats a fantastic value. Also remember to use GCM cipher. it has a better performance. if some time goes by I am sure OpenVPN will be made multithreaded. There is currently a project underway thats called Frivpn that aims to do just that --> making Openvpn able to use more than one core. Just now for linux, hopefully some day for windows. Maybe soon wireguard will replace OpenVPN.... We will see....
  13. 1 point
    This was an issue a year or two ago when I used TorGuard and it still seems to be an issue now. There's nothing you can do to fix it. TorGuard's server config is botched in such a way that you can't negotiate with it. I'll use connecting to UDP port 53 as an example. These are the listed ciphers. cipher AES-256-CBC* cipher AES-128-GCM cipher AES-256-GCM cipher AES-128-CBC cipher BF-CBC A proper OpenVPN server would use cipher AES-256-CBC and then ncp-ciphers AES-256-GCM:AES-128-GCM:AES-128-CBC:BF-CBC. An older OpenVPN client (pre 2.4) would pass cipher AES-256-CBC in their client config. These don't support cipher negotiation, so OpenVPN 2.3 or less, or Open 2.4+ with cipher negotiation disabled, would use AES-256-CBC. But once cipher negotiation is in play (ncp), the cipher config is overridden in favor of ncp-ciphers. An OpenVPN client could pass a list in order of preference and as long as the server accepts them, the first one the server supports gets used. I build my own OpenVPN servers so I have worked with this. An example in my case, I only want to support the AES-256-GCM cipher as I only let the latest clients connect. I set cipher AES-256-CBC as is proper, then ncp-ciphers AES-256-GCM. Since any client with OpenVPN 2.4 by default will use negotiation, and I only list AES-256-GCM, the client absolutely must support and use AES-256-GCM. Technically, they could disable ncp client side and connect with AES-256-CBC (and a 2.3 client might be able to connect, but then I use 2.4+ features so they wouldn't work anyway). I could allow additional ciphers server side by setting ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC. Now, a 2.4+ client with ncp enabled will default to AES-256-GCM, but they can set ncp-ciphers in the client config to force any one of those 4. TorGuard will need to fix their servers to remedy this. There is nothing you can do on your end to force AES-256-GCM properly. I posted here awhile ago about this issue and it looks like they never fixed it. It would also be nice if they would allow SHA-512 on their tls-crypt servers, but at least according to the specs page that no configuration supports that, as opposed to the specs page stating all listed ciphers are valid on 2.4+ despite this being provably false due to their configuration error. On both ASUS Merlin and pfSense, there is no setting that allows me to get AES-256-GCM without the local/remote error and issues that follow from there. So I've just disabled ncp and used AES-256-CBC.
  14. 1 point
    Hello, I've seen many different configurations and I've asked several times in chat. What is the ideal configuration for Torguard? See attachments for what I have set. Is that safe?
  15. 1 point
    Hi, sorry for the stupid question, where do I find the streaming IP and how do I add it to TorGuard? I have bought one and would like to use it Thank-You
  16. 1 point
    Hi. Is there any update on Wireguard Servers? @Support The main reason i interested to this Technology is very little battery usage on smartphones. OVPN usually destroy battery life. I'm testing Wireguard on my own server and battery usage close to Zero. Can you guys provide any ETA for Wireguard servers? Thanks
  17. 1 point
    Hi, I love torguard, it's very fast. I'm using it for some time now. But something I couldn't figure out is the desktop software keeps shutting down on its own 5-10 times a day for some reason. Fortunately I made the firewall block settings, and internet shuts down too, otherwise I would be exposed. I'm using the latest version. If you want me to send you some logs etc. I'll be happy to do it, but you're gonna have to tell me how because logs folder is empty in appdata. I'm using Windows 10 64bit btw.
  18. 1 point
    READ ENTIRE GUIDE BEFORE YOU BEGIN DNS OVER TLS FOR getdns 1.4.2-2 stubby 0.2.3-3 and unbound 1.8.1-2 See here for GETDNS AND STUBBY on OPENWRT / LEDE: https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md - this page is designed for DNS OVER TLS with DNSMASQ but it still is useful and informative . You may also choose to use DNS OVER TLS with DNSMASQ. However, that is not the focus of this tutorial. See Here For OPENWRT STUBBY DNS OVER TLS USING DNSMASQ-FULL FOR DNSSEC & CACHING https://forum.openwrt.org/t/stubby-dns-over-tls-using-dnsmasq-full-for-dnssec-caching/19107 There have been some changes to DNS OVER TLS From The DNS Privacy Project. Here is how to get this up and running. Much remains the same but be aware of the changes from the original guides which I will point out to you along the way. Original posts here: https://forum.openwrt.org/t/from-the-dns-privacy-project-dns-over-tls-on-openwrt-lede-featuring-unbound-getdns-and-stubby/13765 and here: https://torguard.net/forums/index.php?/topic/1374-from-the-dns-privacy-project-dns-over-tls-on-openwrtlede-featuring-unbound-getdns-and-stubby/ By the way I run Davidc502 LEDE Snapshots - Moderately Customized LEDE Development Builds for Linksys 1900ac v.1 and 1900ac v.2, 1900acs v.1 v.2, 3200acm, WRT32X and 1200ac v.1 v.2 series routers. These builds keep up to date package repositories.. GetDns and Stubby are included. Dave's Builds have many other pre-installed common packages as well.. Check out homepage and downloads here: https://davidc502sis.dynamic-dns.net/ and downloads here: https://davidc502sis.dynamic-dns.net/snapshots/ . In addition, there is a very informative, instructive and active thread ( forum ) for Dave's builds and discussion of many OpenWrt / Lede packages, features, and issues. In short great technical advice and assistance can be found here: https://forum.openwrt.org/t/davidc502-wrt1200ac-wrt1900acx-wrt3200acm-wrt32x-builds/ Dave releases new updated builds every two weeks - near the middle and first of each month. I tell you the above because I always have the most up to date packages, linux kernel, wifi drivers and so on. This tutorial may not be for you if you do not have the versions of the software listed in the header of this post. OK - here we go once again. This setup is specifically designed for GETDNS and STUBBY with Unbound DNS and Dnsmasq for DHCP. You can use odhcpd which will handle both DNS and DHCP where you disable and/ or remove DNSMASQ - but you will experience a performance hit. This why I use Unbound/ STUBBY for DNS and Dnsmasq for DHCP. 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/Torsten's Thoughtcrimes However a few modifications are necessary in order to to have GetDns and Stubby up and running and successfully integrated with Unbound DNS and Dnsmasq for DHCP. Refer to this guide while following along with me : https://blog.grobox.de/2018/what-is-dns-privacy-and-how-to-set-it-up-for-openwrt/ 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 Now Let’s Move On 1 - opkg install unbound odhcpd unbound-control unbound-control-setup luci-app-unbound unbound-anchor unbound-host 2 - opkg install getdns stubby As per Torsten's Thoughtcrimes Guide: 3- My WORKING CONFIGS /etc/unbound/unbound_srv.conf ( You Must 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/ for basic guide cat >> /etc/unbound/unbound_srv.conf <<UNBOUND_SERVER_CONF server: # 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: 256m msg-cache-size: 128m # 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 cache-min-ttl: 600 cache-max-ttl: 14400 hide-trustanchor: yes infra-cache-numhosts: 100000 num-queries-per-thread: 4096 max-udp-size: 2048 minimal-responses: yes rrset-roundrobin: yes do-tcp: yes do-ip6: no prefetch: yes prefetch-key: yes qname-minimisation: yes qname-minimisation-strict: yes so-reuseport: yes unwanted-reply-threshold: 10000000 interface-automatic: yes do-not-query-localhost: no use-caps-for-id: yes verbosity: 1 private-domain: "your.domain" harden-referral-path: yes target-fetch-policy: "0 0 0 0 0" val-clean-additional: yes UNBOUND_SERVER_CONF As per Torsten's Thoughtcrimes Guide : Don’t let each server know the next recursion Enter via SSH command line: uci set ‘[email protected][0].query_minimize=1’ 4 - Here is where a major change takes place. On getdns 1.4.2-2 and stubby 0.2.3-3 the /etc/stubby/stubby.yml file DOES NOT control the configuration of STUBBY by default. This has been replaced by the UCI system and the file /etc/config/stubby. I believe that this change to UCI was made to allow for DNSMASQ handling DNS OVER TLS. However, if you are like me - I prefer to still use UNBOUND and this how to do it. See below which is at the top of the /etc/stubby/stubby.yml file - which used to be the only file to configure STUBBY: nano /etc/stubby/stubby.yml - open file and you will see: # 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. 5 - 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: See here for how to configure Stubby: https://github.com/getdnsapi/stubby DNS OVER TLS ABSOLUTE BEST CONFIGURATION FOR STUBBY FOR THE REASONS DETAILED BELOW: nano /etc/stubby/stubby.yml - replace contents of file with configuration below: 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/ 1 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 November 12 2019 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. # 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: 60000 listen_addresses: - [email protected] 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+ - 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 - 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+ - 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 dns.containerpi.com DNS TLS Server A+ - 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 doh.li DNS TLS Server A+ - address_data: 46.101.66.244 tls_auth_name: "doh.li" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: uvzicx/TyvOXaow4tea2C6e2j5jtz44P8JnjVDa6/yY= ## 6 - The Andrews & Arnold DNS TLS Server #1 A+ - address_data: 217.169.20.23 tls_auth_name: "dns.aa.net.uk" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: qcahcJ8VhWz83citsQsOXC/qoCK3b20ja58MZMMnAIg= ## 7 - The Andrews & Arnold DNS TLS Server #2 A+ - address_data: 217.169.20.22 tls_auth_name: "dns.aa.net.uk" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: MjpiTbfaE5lFDLkL8iMFbmN/OOlcxtmIvxCfWLOPa3c= ## 8 - 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= ## 9 - 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: lI/c+XiSmaAm79YulIzRmskcP7MAAD4G4uaD3iLs3Bk= ## 10 - 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: QJfVWq6mEFRx5RSUgxSwn9Eu6VBFTRxQYJFjnIBamqU= ## 11 - 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= ## 12 - The dns.seby.io - Vultr DNS TLS Server A+ - address_data: 45.76.113.31 tls_auth_name: "dot.seby.io" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: H13Su1659zEn0ZIblEShwjZO+M5gxKK2wXpVKQHgibM= ## 13 - The dns.seby.io - OVH 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= ## 14 - The 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: yJ5GuTCv9+gRyR78zryHT38gTJ0lmAcsXZXTH/XVA0Y= ## 15 - The Secure DNS Project by PumpleX DNS TLS Server #1 A+ - address_data: 51.38.83.141 tls_auth_name: "dns.oszx.co" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: QowCiUIaOZeJN5lNa+V/NEVXvXrc5BOPyBargT5xpZQ= ## 16 - The Secure DNS Project by PumpleX DNS TLS Server #2 A+ - address_data: 51.38.82.198 tls_auth_name: "dns.pumplex.com" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: GGR/Mugb+WNqMmxTI0pHjRJsY96XjzlVDqVuqQ8Cknw= ## 17 - 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: croPLPRgIm4Oi8/lXsDsbbTVXFa9RL39HuS0gTg7Epo= ## 18 - 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: BlkbTR4gX+PKMeqX4/WOpZzjlsnWVyj9Bw9U3goVrk4= ## 19 - 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: A3BOLaaLUejVlNgVmVfTm1vDzHP1dfXlBXs8yQUE4Ew= ## 20 - 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: 9QK9j+GK8Vc6HrzAGlwxjKL+dWGe/fpLjleufiKKU6o= ## 21 - The jp.tiar.app DNS TLS Server A+ - address_data: 172.104.93.80 tls_auth_name: "jp.tiar.app" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: TYnXRNrX7Bedqr7G0uIZYksMk1Xux1GtnZQniwLkzsY= ### Anycast DNS Privacy Public Resolvers ### ## 22 - The DNS.SB DNS TLS Server #1 A+ - address_data: 185.222.222.222 tls_auth_name: "dns.sb" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k= ## 23 - The DNS.SB DNS TLS Server #2 A+ - address_data: 185.184.222.222 tls_auth_name: "dns.sb" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k= ## 24 - The dns.quad9.net DNS TLS Server A+ - 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= # 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_2 ## For Version OpenSSL 1.1.1 TLSv1.3 and above # 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 # 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" Save and Exit 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/configuration/19474f/setup 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. 6 - Now from the Torsten's Thoughtcrimes Guide again - My WORKING CONFIG /etc/unbound/unbound_ext.conf cat >> /etc/unbound/unbound_ext.conf <<UNBOUND_FORWARD_CONF forward-zone: name: "." # Allow all DNS queries forward-addr: [email protected] UNBOUND_FORWARD_CONF 7 - Once again follow the steps in Torsten's Thoughtcrimes Guide # 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 # Restart (or start) unbound (System -> Startup -> unbound -> Restart) /etc/init.d/unbound restart 8 - From https://github.com/openwrt/packages/tree/master/net/unbound/files HOW TO Integrate with DHCP Parallel DNSMASQ nano /etc/config/dhcp After Some Reflection and Observations - Fine Tuning Your DNS Resolver After reading System Logs I realized that there is a need to amend DNSMASQ ( DHCP ) after implementing option noresolv ‘1’ in /etc/config/dhcp configuration file. This dawned on me from my years of running DNSCRYPT Proxy on OpenWrt. I referred to this guide: Go to this section near bottom of page. Use specific DNS server to lookup one or more host names https://www.leowkahman.com/2016/05/23/openwrt-encrypted-dns-lookup-using-multiple-dnscrypt-servers/ option noresolv ‘1’ is to prevent using any upstream DNS server other than those specified in this file # this file being: /etc/config/dhcp Solution is as follows add these two lines to /etc/config/dhcp: or using UCI uci add_list [email protected][-1].server='127.0.0.1#5453' uci set [email protected][-1].noresolv=1 uci commit && reload_config or nano /etc/config/dhcp - enter these lines before / option domain ‘yourdomain’ list server '127.0.0.1#5453' # Stubby/Unbound Default Address/Port option noresolv ‘1’ # Make sure to change this as indicated After you complete all the steps in this tutorial and restart your Router Check Status > System Log - You will find an entry like the one below: daemon.info dnsmasq[8532]: using nameserver 127.0.0.1#5453 - which indicates that your OpenWrt Router is using Unbound and Stubby for Encrypted DNS Resolution 9 - Now go to the default UNBOUND configuration file /etc/config/unbound and enter the following : Open file by SSH nano /etc/config/unbound - then only replace the config unbound - leave the config zone entries as they are config unbound option dns64 '0' option edns_size '4096' option extended_luci '1' option hide_binddata '1' option enabled '1' option listen_port '53' option localservice '1' option luci_expanded '1' option manual_conf '0' option rebind_localhost '0' option rebind_protection '1' option recursion 'passive' option resource 'medium' option root_age '9' option ttl_min '120' option unbound_control '2' option validator '1' option validator_ntp '1' option query_minimize '1' option query_min_strict '1' option dhcp_link 'dnsmasq' option protocol 'ip4_only' option prefetch_root '0' option extended_stats '1' list trigger_interface 'lan' list trigger_interface 'wan' 10 - For DNS OVER TLS resolution add Custom DNS resolver as follows: using UCI uci set network.wan.peerdns='0' uci set network.wan.dns='127.0.0.1' uci set network.wan6.peerdns='0' # if you use Stubby for IPV6 uci set network.wan6.dns='0::1' # if you use Stubby for IPV6 uci commit or Via Luci Interface Under Network > Interfaces > Edit Wan > Advanced Settings > Remove Check From Box Next To " Use DNS servers advertised by peer " and enter DNS Server 127.0.0.1 - 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. 11 - VERY IMPORTANT STEP - after setting your DNS to 127.0.0.1 ( you need 127.0.01 as this is what both Stubby and Unbound use as their local resolver ) You must run /etc/init.d/unbound restart one more time. When you do this you will see that your unbound root.key will be installed to /var/lib/unbound/root.key and also it will install root.key to /etc/unbound/root.key. This will automatically configure DNSSEC on your router. The function also lists your auto-trust anchor in your /var/lib/unbound/unbound.conf file. 12 - DNS query name minimisation to improve privacy, along with DNS resolution speed and accuracy - Run Test After Completing Full Setup. These name servers listed above help to consistently ensure QNAME Minimisation functions as designed within UNBOUND ( The idea is to minimise the amount of data sent from the DNS resolver to the authoritative name server. ) Use either or both of these two methods to verify QNAME Minimisation A - You need to opkg install drill and - then run command : drill txt qnamemintest.internet.nl and / or B - opkg install bind-dig or opkg install bind-tools with 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 in " /etc/unbound/unbound_srv.conf " file. qname-minimisation: yes qname-minimisation-strict: yes harden-below-nxdomain: yes 13 - I have found that for whatever reasons it is best to make these entries in startup in order for stubby and unbound to fire up after a reboot. On boot, in case GetDns and Stubby fails to start. This is very likely due to Internet connection not available yet at time of starting Unbound GetDns and Stubby. In such a case, the workaround is to wait for Internet connection to be available before restarting Unbound GetDns and Stubby. Add the following lines into /etc/rc.local: You may also enter these additions via Luci menu Startup > Local Startup nano /etc/rc.local # Put your custom commands here that should be executed once # the system init finished. By default this file does nothing. # Wait until Internet connection is available for i in {1..60}; do ping -c1 -W1 99.192.182.100 &> /dev/null && break; done # Restart DNS Privacy Daemon - Stubby as it requires a successful #time sync for its encryption to work/ /etc/init.d/unbound restart /etc/init.d/stubby restart /etc/init.d/openvpn restart #If you run VPN as you should exit 0 14 - You will now be running DNS OVER TLS with GETDNS and Stubby on LEDE / OpenWrt Make sure to follow this guide precisely and it works GREAT!!! You can check logs under Services > Recursive DNS > Status > Log - you will see that you have a caching encrypted DNS Resolver !!! Bonus Setup Option ( Highly Recommended ) - Install WatchCat http://www.ibuyopenwrt.com/index.php/2-uncategorised/224-watchcat-reboot-on-internet-drop I set "Reboot on Internet Connection Lost" option. I have WatchCat set to ping Fourth Estate DNS address - 179.43.139.226 - every 20 minutes. This will keep your router up and running consistently. 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 is a sure fire method 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 opkg install gnutls-utils 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 There is also a third option. kdig -d @185.49.141.37 +tls-ca +tls-host=getdnsapi.net example.com - where you must install knot-dig / opkg install knot-dig This is my personal favorite as the readout from this command will list the certificate specifically like so: ;; DEBUG: #1, CN=getdnsapi.net ;; DEBUG: SHA-256 PIN: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q= and let you know that the certificate is valid like so: ;; DEBUG: TLS, The certificate is trusted. Remember to change port to 443 or port for IPV6 if different than standard 853 where applicable. To use kdig certificate verification method on an alternate port example: kdig -d @199.58.81.218 -p 443 +tls-ca +tls-host=dns.cmrg.net example.com 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. Lastly, you can check your DNS at GRC Spoofability Test - DNS Leak - or any of 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. https://www.dnsleaktest.com/ https://www.perfect-privacy.com/dns-leaktest/ https://www.grc.com/dns/dns.htm http://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/ See here for TorGuard Open VPN Setup https://torguard.net/forums/index.php?/topic/1247-lede-openwrt-torguard-vpn-setup/ And now you are cooking with plenty of Gas - c'est fini c'est manifique c'est ci bon Peace and Grace Unto All, directnupe Parting Thoughts: My reason for preferring to configure Stubby with the /etc/stubby/stubby.yml file instead of the now default UCI system /etc/config/stubby file is for the following reasons. 1- I found that I had more control over the security options which DNS OVER TLS is intended to provide. Like padding - 853 or 443 port and so on. 2 - In my testing UCI system /etc/config/stubby file configurations did not work well with UNBOUND. As I said, I believe that this is for native DNSMASQ on Openwrt. For instance, there is an entry option appdata_dir '/var/lib/stubby' - this is for Stubby to do DNSSEC as DNSMASQ does do not do this. 3 - In short, I prefer UNBOUND along with STUBBY and GETDNS as NLnet Labs develops all of these components which were constructed to implement DNS OVER TLS ( aka DNS PRIVACY ). I am sure that they will do their best to make sure that all of these components work well together. Others may think otherwise and I respect that. However, the major point is that NLnet Labs is running " The Whole GETDNS STUBBY / UNBOUND Show " - so that is a good thing that one developer is handling all components needed for DNS OVER TLS.
  19. 1 point
    Hi, for some time now I've noticed that the download speed on different servers have decreased dramatically. I can only get relatively decent speeds when using the closest server. Anything further away drops to 10-20% of the achievable speed without using VPN. For testing I have used: https://www.thinkbroadband.com/download These are the settings I'm using: Any suggestions? C3ll
  20. 1 point
    You should consider the Asus RT-AC86U and flash with Merlin firmware. The router has hardware acceleration and an 1800MHz processor. The built in vpn client makes it real simple to add TG or other OpenVPN service, especially with Merlin FW which has numerous very useful tweaks over Asus stock FW. I used Asus 68U and 88U prior and the 86U increases vpn speeds more than 50%. It's an awesome router for handling vpn. Has LAN-IPTV built in as well.
  21. 1 point
    Thanks for your suggestions, we are working to improve port forwards and will take note Regards
  22. 1 point
    I don't have much knowledge on the subject and need someone to explain certain aspects to me. I have done some research but online research isn't very friendly to someone who has limited knowledge on the subject in the first place. This thread could also be a future reference to others who use the VPN but are not very informed on what certain aspects are. - What's the different between OpenVPN and OpenVPN V2.4? -What's the different between enabling STunnel and not enabling it on the Torguard Client? -Should I be using STunnel? -Does stealth actually hide what VPN server i'm connecting to (NY, LA, Etc.), or does it only disguise my traffic to look like normal traffic from said server? -Is there any way around websites which specifically block the use of VPN's or proxies? Stealth connections don't seem to work all the time, at least for me.
  23. 1 point
    Customer support is really good at fixing speed issues. They usually suggest doing the following when using the TORguard app Please click more Settings-> Network on the VPN app Uncheck the block outside DNS boxLocate three drop downs under the " use these nameservers" section Choose Google under all three of them on by oneClick Save and restart App firstTry to ConnectPlease connect with tunnel type as Open Connect and Protocol as UDP this time. I recently changed ISP providers to also get 100/10 service and the same setting above were not working for me. I kept google as the name servers and went back to tunneltype = OPENVPN, protocol UDP, port 1195(SHA 256) Ciper AES-256-CBC The servers closest to me I was getting about 60-70 Mbps, if you in USA, the Chicago server seems to connect fastest for me I now get 108/11 when connected to torguard. Before I made changes my downloads would not get pass 20. Try the first suggestion as this is what Torguard support usually recommends.
  24. 1 point
    Hi Simon Is this the latest Tg Android app your running ? right now it will auto connect on boot or connect but not on application start - we do plan on adding this, i will try get it pushed in the next release. Regards
  25. 1 point
    Uk Manchester other providers have manchester
×