Jump to content

Search the Community

Showing results for tags 'security'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


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

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...

Found 7 results

  1. Dear TorGuard OpenWrt Users, Hello - and I hope that you are well. This is how to get and setup Let's Encrypt Certificate using DuckDNS on OpenWrt. If you follow these instructions you should have no problems at all. I picked DuckDns because - it allows you five Domains ( read sub-domains ) and supports Let's Encrypt on OpenWrt. First go to https://www.duckdns.org/ - Log in order create account. I use reddit to sign in - DuckDNS also offers Google, Twitter, GitHub, or Persona logins to create an account. You are allowed five sub domains - create one - name it would you like - something like secureone. Your full sub domain is now- secureone.duckdns.org - Click on " install " on the top banner - go to " first step - choose a domain " and from the drop down menu - select the sub-domain you just created - secureone.duckdns.org - then under " Routers " - select " OpenWrt " - you will then get these instructions: find them below the DuckDNS DDNS SCRIPT SECTION. Before You Begin You Should Make HOSTNAME under System something like cryptorouter ( or whatever you like ) and under Network > DHCP and DNS > Local domain - enter something like - home.secureone.duckdns.org When you are done this is the FQDN that your Let's Encrypt Certificate will named - in this example it is as follows : cryptorouter.home.secureone.duckdns.org DuckDNS DDNS SCRIPT SECTION: First, I use a script to update DuckDNS DDNS service. See here : https://www.bytebang.at/Blog/Find+public+IP+address+for+OpenWRT+via+Script# To implement this script, please follow these instructions below: opkg update ; opkg install knot-dig -- then: nano /usr/lib/ddns/getPublicIp.sh enter this script below in the new file : #!/bin/sh # sample script for detecting the public IP kdig +short myip.opendns.com @resolver1.opendns.com make it executable = chmod +x /usr/lib/ddns/getPublicIp.sh DuckDNS OpenWrt DDNS SETUP : opkg update opkg install ddns-scripts ## Davidc502 SnapShots Come With This Pre-Installed edit the config at /etc/config/ddns nano /etc/config/ddns ## Replace The IPV4 Configuration With The Contents Below: config service 'duckdns' option enabled '1' option username 'secureone' option domain 'secureone.duckdns.org' option password 'f8be3d28-104e-45d2-a5a9-e95599b84ae2' ## Use Your Own DuckDNS PassWord - This one is a fake option interface 'wan' option check_interval '5' option check_unit 'minutes' option force_interval '24' option force_unit 'hours' option ip_source 'script' option retry_interval '60' option retry_unit 'seconds' option ip_script '/usr/lib/ddns/./getPublicIp.sh' option update_url 'https://www.duckdns.org/update?domains=[USERNAME]&token=[PASSWORD]&ip=[IP]' option use_https '1' option cacert '/etc/ssl/certs/ca-bundle.crt' option lookup_host 'secureone.duckdns.org' Next here are the correct commands for SSL HTTPS DuckDNS below: opkg update opkg install curl ## Davidc502 SnapShots Come With This Pre-Installed mkdir -p /etc/ssl/certs ## Directory Exists Already On Davidc502 SnapShots Issue This Most Important Command Below: curl -k https://certs.secureserver.net/repository/sf_bundle-g2.crt > /etc/ssl/certs/ca-bundle.crt Now Start DDNS : sh . /usr/lib/ddns/dynamic_dns_functions.sh # note the leading period start_daemon_for_all_ddns_sections "wan" exit ## Very Important To Exit we can now test the script by running the command /usr/lib/ddns/dynamic_dns_updater.sh duckdns Then Check DDNS under Services Is Up And Running. Now that you have DuckDNS Service running on your OpenWrt Router - let us install Let's Encrypt Certificate. First you must issue these commands: uci delete uhttpd.main.listen_http uci set uhttpd.main.redirect_https=1 uci set uhttpd.main.rfc1918_filter='0' ## This allows you to login with public sub-domain uci commit /etc/init.d/uhttpd restart Now install necessary Let's Encrypt packages as follows : opkg update ; opkg install socat ncat luci-app-acme acme-dnsapi acme coreutils-stat ## acme-dnsapi is themost important one Then issue certificate with this command: ## Token is your DuckDNS Password & Please Note FQDN Placement DuckDNS_Token="f8be3d28-104e-45d2-a5a9-e95599b84ae2" /usr/lib/acme/acme.sh --issue -d cryptorouter.home.secureone.duckdns.org --dns dns_duckdns The issuance takes 120 seconds to complete after acme challenge ; when finished You can locate the certificate and key files in ./.acme.sh/your.domain/, and then in the uHTTPd settings point the certificate and key path to them respectively This means that the two main files you need are found here : /root/.acme.sh/cryptorouter.home.secureone.duckdns.org/cryptorouter.home.secureone.duckdns.org.cer /root/.acme.sh/cryptorouter.home.secureone.duckdns.org/cryptorouter.home.secureone.duckdns.org.key Now edit /etc/config/uhttpd file thusly as demonstrated below: ## Notice that I set https ONLY earlier and now the login port is set to " 10445 " nano /etc/config/uhttpd config uhttpd 'main' list listen_https '' list listen_https '[::]:10445' option redirect_https '1' option home '/www' option max_requests '3' option max_connections '100' option cert '/root/.acme.sh/cryptorouter.home.secureone.duckdns.org/cryptorouter.home.secureone.duckdns.org.cer' option key '/root/.acme.sh/cryptorouter.home.secureone.duckdns.org/cryptorouter.home.secureone.duckdns.org.key' option cgi_prefix '/cgi-bin' list lua_prefix '/cgi-bin/luci=/usr/lib/lua/luci/sgi/uhttpd.lua' option script_timeout '60' option network_timeout '30' option http_keepalive '20' option tcp_keepalive '1' option ubus_prefix '/ubus' option rfc1918_filter '0' config cert 'defaults' option days '730' option bits '4096' option country 'US' option state 'Texas' option location 'Austin' option commonname 'OpenWrt' then issue this command : chmod 400 /root/.acme.sh/cryptorouter.home.secureone.duckdns.org/cryptorouter.home.secureone.duckdns.org.key At this point DO NOT !! - I REPEAT DO NOT !! - DO NOT RESTART " uhttpd " for any reason whatsoever. Instead clear your browser - close - clean cookies and all that good stuff. Then open your browser and login with - https://cryptorouter.home.secureone.duckdns.org:10445 - as per this example. You should not be prompted by " insecure warning " any longer - and the green padlock will appear in the address bar. Click on it and see the certificate details if you wish. NEXT CONFIGURE ACME FOR AUTOMATIC RENEWAL edit /etc/config/acme as below: nano /etc/config/acme config acme option state_dir '/root/.acme.sh/' option account_email '[email protected]' ## Fake E-mail Too option debug '1' config cert 'example' option keylength '4096' option update_uhttpd '1' option enabled '1' option webroot '/www' list domains 'cryptorouter.home.secureone.duckdns.org' option use_staging '0' option dns 'acme.sh --insecure --issue --dns dns_duckdns -d cryptorouter.home.secureone.duckdns.org' list credentials 'export DuckDNS_Token="f8be3d28-104e-45d2-a5a9-e95599b84ae2"' Then issue these commands : /etc/init.d/acme start and /etc/init.d/acme enable BONUS : In order to preserve your Let's Encrypt Certificates - use WINSCP and go into default directory. In this case open : /root/.acme.sh/cryptorouter.home.secureone.duckdns.org/ on the right side of the window. You will see all the certificates and associated files. Save them to a folder on your desktop USB or what have you in case you need to upgrade or install new OpenWrt - for instance, Dave puts out new SnapShots every two weeks approximately. As you know, Let's Encrypt Certificates are good for 90 days and you do not want to abuse this free service. You can reuse them via WINSCP - make sure to create and install them to proper directory on new install as follows- issue command: mkdir -p /root/.acme.sh/cryptorouter.home.secureone.duckdns.org/ Then WINSCP the saved Let's Encrypt Files from your previous storage desktop directory or USB into this newly created router directory. That is after you setup DuckDNS - installed necessary ACME packages and follow all the instructions above EXCEPT for creating a new certificate. Do not forget this command either: chmod 400 /root/.acme.sh/cryptorouter.home.secureone.duckdns.org/cryptorouter.home.secureone.duckdns.org.key Remember all of this was done using " fictional " hostname, local domain - DuckDNS token and so on ; however, it does illustrate how to get you going. I find DuckDNS very easy to implement and manage. I also use DuckDNS on pfSense and OPNsense.
  2. How to configure uTorrent on Windows Various optimizations and security tweaks. Step 1: Open uTorrent settings Step 2: Configure Connection Step 3: Configure Bittorrent Step 4: Bind to VPN IP (optional, requires VPN) Step 5: Disable advertisements Step 6: Block uTorrent from Windows host file (optional) Step 7: Testing for leaks
  3. Taurean

    TLS 1.3

    Hello -- When do you plan to implement TLS v1.3? Just curious.. It's been out for a while now, and as a company in the security business, you'd be ahead of others. Thanks.
  4. Interesting read... https://uk.pcmag.com/torguard-vpn/116817/news/compression-and-vpns-make-for-leaked-secrets
  5. READ ENTIRE GUIDE BEFORE YOU BEGIN See here for GETDNS AND STUBBY on OPENWRT / LEDE: https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md OPENWRT STUBBY DNS OVER TLS USING UNBOUND: https://forum.openwrt.org/t/from-the-dns-privacy-project-dns-over-tls-on-openwrt-lede-featuring-unbound-getdns-and-stubby/13765 https://torguard.net/forums/index.php?/topic/1374-from-the-dns-privacy-project-dns-over-tls-on-openwrtlede-featuring-unbound-getdns-and-stubby/ I have written tutorials where DNS OVER TLS setup is focused on deploying UNBOUND STUBBY and GETDNS along with DNSMASQ for DHCP on OPENWRT/LEDE. Thanks to my good friend Specimen ( see his tutorial / guide here : https://forum.openwrt.org/t/tutorial-dns-over-tls-with-dnsmasq-and-stubby-no-need-for-unbound/18663 - I was able to realize that we can eliminate UNBOUND all together for those who wish to do so for any number of reasons. For those of you who that may have limited memory or storage available on your router and you need more storage and swap memory for your router see here: http://ediy.com.my/index.php/blog/item/118-how-to-increase-storage-on-tp-link-tl-mr3020-with-extroot and here: https://samhobbs.co.uk/2013/11/more-space-for-packages-with-extroot-on-your-openwrt-router -Specimen's tutorial features a method to install STUBBY and GETDNS to RAM very smartly and efficiently as well - that will not be covered here as I have found that DNSMASQ-FULL is a better solution in my opinion. So - let's get started with no further ado: 2 - A - opkg update B - opkg install ca-certificates C - opkg install stubby ( GETDNS and LIBYAML will be installed as dependencies ) 3 - This guide aforementioned at the top of this page: https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md is the one I followed. However, the only issue is that the guide gives one several options as to how to deploy STUBBY and GETDNS with DNSMSQ and / or DNSMSQ-FULL. With the availability of options just may come confusion and mistakes. So, the purpose of this tutorial is to demonstrate how to eliminate potential errors during setup of STUBBY DNS OVER TLS USING DNSMASQ-FULL FOR DNSSEC & CACHING as the title asserts. 4 - I chose 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. 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: 6 - The next step is to configure /etc/stubby/stubby.yml file in the standard fashion. Note that DNSSEC is not configured in STUBBY as DNSMASQ-FULL will be configured to implement this feature later on in this process. Here is my /etc/stubby/stubby.yml file nano /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/ 1 I will save you some considerable leg work and post below the best configuration for your stubby.yml file. Here it is: ## Tested On https://cmdns.dev.dns-oarc.net/ May 20 2019 A Rating - Perfecto Configuration # 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] - 0::[email protected] ## If you use IPV6 Servers dns_transport_list: - GETDNS_TRANSPORT_TLS tls_connection_retries: 5 tls_backoff_time: 900 timeout: 2000 upstream_recursive_servers: # IPV4 Servers ### DNS Privacy Test Servers ### ## The Surfnet/Sinodun DNS TLS Server - address_data: tls_port: 853 tls_auth_name: "dnsovertls3.sinodun.com" tls_pubkey_pinset: - digest: "sha256" value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8= # The securedns.eu DNS TLS Server dot.securedns.eu - address_data: tls_auth_name: "dot.securedns.eu" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g= #The BlahDNS German DNS TLS Server - address_data: tls_auth_name: "dot-de.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: GsfF6a28usi59J/pUUtqbyfmmyKE7+7OfzdLXzUt/Aw= #The BlahDNS Japan DNS TLS Server - address_data: tls_auth_name: "dot-jp.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: B0mMSct7Bbz4E7Lk6BwXuVzdxA1KuYtDs8pw7uaPmB4= #The DNS Warden DNS TLS Primary Server - address_data: tls_auth_name: "dot1.dnswarden.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: deCWLScS/hqOKvzPDNr9JZdoBYsrWM7AWQ56biseGxA= #The DNS Warden DNS TLS Secondary Server - address_data: tls_auth_name: "dot2.dnswarden.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: deCWLScS/hqOKvzPDNr9JZdoBYsrWM7AWQ56biseGxA= #The Primary appliedprivacy.net DNS TLS Server - address_data: tls_auth_name: "dot1.appliedprivacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: ScYkwTIhR1AZGwAsy9Fgn+ET70+t8HR8giYq9abl7tA= #The ibksturm DNS TLS Server - address_data: tls_auth_name: "ibksturm.synology.me" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: v9DZ6wtFZcs26wzq6lwHSlcV6o0Nvw/9pLiBarQJfQE= #The Secure DNS Project by PumpleX DNS TLS Server - address_data: tls_auth_name: "dns.oszx.co" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: P/Auj1pm8MiUpeIxGcrEuMJOQV+pgPY0MR4awpclvT4= ### Anycast DNS Privacy Public Resolvers ### #Quad9 'secure' DNS TLS Secondary Server - address_data: tls_auth_name: "dns.quad9.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: /SlsviBkb05Y/8XiKF9+CZsgCtrqPQk5bh47o0R3/Cg= tls_min_version: GETDNS_TLS1_3 tls_ciphersuites: "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256" 7 - Integration of STUBBY with DNSMASQ A - Set DNSMASQ to send DNS requests to STUBBY - this is done to allow Localhost ( ) on port 5453 to be the sole resolver used by your router. This forces router to use DNS OVER TLS as STUBBY listens on the default address / port . There are two methods to do this: uci add_list [email protected][-1].server='' uci set [email protected][-1].noresolv=1 uci commit Or edit the /etc/config/dhcp file nano /etc/config/dhcp list server '[email protected]' option noresolv '1' 8 - Disable Sending DNS Requests to ISP Provided DNS Servers uci set network.wan.peerdns='0' uci set network.wan.dns='' 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 In the Luci Web interface under Network > Interfaces > Edit Wan > Advanced Settings > Remove Check From Box Next To " Use DNS servers advertised by peer " and enter DNS Server - 9 - Now restart DNSMASQ and enable, start and restart STUBBY just to make sure everything is up and running before you proceed. Run the following commands: /etc/init.d/dnsmasq restart /etc/init.d/stubby enable /etc/init.d/stubby start /etc/init.d/stubby restart 10 - Enabling DNSSEC - We are going to use DNSMASQ-FULL in order to enable this feature. This one command removes DNSMASQ and installs DNSMASQ-FULL. In order to achieve this end, enter this as one command: A - opkg install dnsmasq-full --download-only && opkg remove dnsmasq && opkg install dnsmasq-full --cache . && rm *.ipk 11 - We are now going to configure STUBBY not to perform DNSSEC validation and configure DNSMASQ-FULL to require DNSSEC validation. We do so by entering the following commands via UCI: uci set [email protected][-1].dnssec=1 uci set [email protected][-1].dnsseccheckunsigned=1 uci commit Or edit the /etc/config/dhcp file nano /etc/config/dhcp option dnssec '1' option dnsseccheckunsigned '1' To verify DNSSEC trust-anchors, this is how to do it ( 1 ) trust-anchors are here: TRUSTANCHORSFILE="/usr/share/dnsmasq/trust-anchors.conf" so in SSH shell issue command : cat /usr/share/dnsmasq/trust-anchors.conf - and Voila' - Whoop There It Is ! 12 - Now I am used to running UNBOUND so I accustomed its' caching feature. To increase DNSMASQ-FULL cache use one of these two methods: A - Via UCI (Unified Configuration Interface) - in shell uci set [email protected][0].cachesize=1000 uci commit dhcp Or edit the /etc/config/dhcp file nano /etc/config/dhcp option cachesize '1000' Now restart DNSMASQ and restart STUBBY once again: /etc/init.d/dnsmasq restart /etc/init.d/stubby restart 13 - I have found that for whatever reasons it is best to make these entries in startup in order for STUBBY and DNSMASQ-FULL 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 DNSMASQ-FULL GETDNS and STUBBY. In such a case, the workaround is to wait for Internet connection to be available before restarting DNSMASQ-FULL GETDNS and STUBBY. The solution is to 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 &> /dev/null && break; done # Restart DNS Privacy Daemon - Stubby as it requires a successful #time sync for its encryption to work/ /etc/init.d/dnsmasq restart /etc/init.d/stubby restart /etc/init.d/openvpn restart #If you run VPN as you should exit 0 Reboot your router just to make sure everything is running as designed. 14 - Two quick command line tests for you to conduct after rebooting your router: A - DNS query name minimisation to improve privacy, along with DNS resolution speed and accuracy. The name servers listed I use help to consistently ensure QNAME Minimisation functions as designed. The idea is to minimise the amount of data sent from the DNS resolver to the authoritative name server. You need to opkg install bind-tools or opkg install bind-dig command : dig txt qnamemintest.internet.nl +short and / or dig -t txt qnamemintest.internet.nl 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. B - DNSSEC TEST - command : dig dnssectest.sidn.nl +dnssec +multi @ Look at the flags section. You should see : ;; flags: qr rd ra ad; As long as you get ad flag as you should, you now have verified DNSSEC as well. VERY IMPORTANT TIP: Please note that right at the top of the main DNS Privacy Test Servers Homepage ( https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers ) It Ominously Declares: DoT servers The following servers are experimental DNS-over-TLS servers. Note that they are experimental offerings (mainly by individuals/small organisations) with no guarantees on the lifetime of the service, service level provided. The level of logging may also vary (see the individual websites where available) - the information here about logging has not been verified.Also note that the single SPKI pins published here for many of these servers are subject to change (e.g on Certificate renewal) and should be used with care!! For these reasons it is most important to check and verify your SPKI pin(s) for TLS authentication manually yourself from time to time. There are sure fire methods to make sure that you are using the correct value for any upstream nameserver ( aka tls_pubkey_pinset value ) - Go to https://blahdns.com/ and scroll down to the section to the yellow section entitled What is DNS OVER TLS click on it and it will open up. When you do it will state some general information, but what you want to pay attention to is this section: How to get SPKI gnutls-cli --print-cert -p 853 - where you must opkg install gnutls-utils OR echo | openssl s_client -connect '' 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 @ +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 @ -p 443 +tls-ca +tls-host=dns.cmrg.net example.com Peace Unto All, directnupe Parting Thoughts: I really like this deployment and implementation of DNS OVER TLS. It seems to be very snappy in resolving DNS queries - even a bit more responsive than UNBOUND. It is pretty simple and straight forward to set up and the documentation is very easily understood. Moreover, DNSMASQ is the native resolver for OpenWRT, so this set up minimizes any other components which may bog down your router. In essence, this setup is most clean and elegant in my estimation. Also, DNSMASQ-FULL allows you a more robust resolver than the native install standard DNSMASQ version. DNSMASQ-FULL allows for DNSSEC and QNAME Minimisation. I am using this setup now and I will report back later on; however, for now it is working beautifully.
  6. Hello, i guess most people have heard about the cloudbleed bug. if not: https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/ Since TorGuards Website also uses it, maybe everyone here should change his/her password and activate 2FA.
  7. Not bad at all for simply connecting but as you see, even connecting to torguard brings issues if your ISP is spying on you. This is very good example of something, where other tests show you that everyhing is ok but this test clearly shows you that your ISP is hijacking DNS. You need to have Java installed on your pc to run these tests, it does not work in chrome, but on firefox it does even if using combination of proxifier and foxyproxy (because java tool does all the job, not the browser itself) TEST NOW WITH ANALYZR Good article in german explaining it a little bit and includes the test itself. Send your tests to TorGuard support, they will help you very fast with any leaks, problems or even unintentionally missconfigured device like to open ports which you do not want at all opened. Here is one example (it provides a link which you can send to torguard support if your tests show any issues): More test results (example):