All Activity

Changelog: - Fixed WebRTC Issues - Removed the Type field with HTTPS/HTTP selection - only encrypted connections are allowed. - Added ability to click Disconnect or select and switch to another server in the Connecting and Verifying IP states - Some minor Internal bugs fixed. Downloads

I still had to switch to the Classic interface to avoid this problem.

Thanks for this, I was beginning to think all kinds of horrors had happened to my system. It worked fine for me under v4.7.5. Hope they fix it sometime.

?4?) ?guide? should be about something connected or about services torguard offers? Asking this just to prevent the headache for you later when people start submitting unique guides of as example: How to write simple Hello World script i X lang, in Y lang, ... Also, if guide is available in another language, how will you know it is unique if it is translated? Asking those questions as such things are something that trolls love and is not bad for starting trolling with undefined replies as they were not defined, not to mention bots copy/pasting available guides just in another language, like as example, would my wireguard guide count twice if I translate it to lets say russian? Probably not, but on other side it takes time to translate and might be help other users. From that perspective, sure, good if translator is rewarded too, but if every guide is translated into all languages you will have to give quite many months for free for every guide (even if you have no users speaking that language). Maybe your marketing team knows about it more, but honestly, define it more strickly to prevent confusion and frustration of your potenitial guide writters. For the rest I find this is a good idea.

Dear Community, First you all know the drill by now - " The Intro " - two throwbacks - https://www.youtube.com/watch?v=m5FCcDEA6mY - lyrics - https://genius.com/Neil-young-southern-man-lyrics - and don't you know - https://www.youtube.com/watch?v=wkA7ok5MySk - https://genius.com/Funkadelic-if-you-dont-like-the-effects-dont-produce-the-cause-lyrics - OK - now that our long standing tradition of public elucidation has been fulfilled - let's get down to the business at hand. 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 predate 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. However, there has been a minor change ( yet little known ) in UNBOUND on OPNsense 21.7.1 with regard to configure it to work with Stubby for DNS Privacy DNS OVER TLS. So, let's get started strait away. See here for previous more in depth guide concerning the benefits of DNS Privacy : https://bit.ly/3j0QT1l So here we go. So go ahead and issue command : A - # pkg install getdns in order to get started. After installing getdns which includes stubby follow the steps below. 1 - 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: A - # su -m unbound -c /usr/local/sbin/unbound-anchor Then - B - Issue this command : # mv /usr/local/etc/rc.d/stubby /usr/local/etc/rc.d/stubby.sh Make it executable - I run this command - it works for me: C - # chmod 755 /usr/local/etc/rc.d/stubby.sh D - Yes must enable Stubby Daemon in the file - open file by : E - # 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 already configured. Save and exit. 2 - Now you must configure Stubby to resolve DNS OVER TLS - enter command below : A -# nano /usr/local/etc/stubby/stubby.yml - make your file match some thing similar to this ################################################################################ ######################## STUBBY YAML CONFIG FILE ############################### ################################################################################ # This is a yaml version of the stubby configuration file (it replaces the # json based stubby.conf file used in earlier versions of getdns/stubby). # # For more information see # https://dnsprivacy.org/wiki/display/DP/Configuring+Stubby # resolution_type: GETDNS_RESOLUTION_STUB dns_transport_list: - GETDNS_TRANSPORT_TLS tls_authentication: GETDNS_AUTHENTICATION_REQUIRED tls_query_padding_blocksize: 128 edns_client_subnet_private : 1 idle_timeout: 9000 listen_addresses: - [email protected] - 0::[email protected] tls_connection_retries: 5 tls_backoff_time: 900 timeout: 2000 round_robin_upstreams: 1 tls_ca_file: "/usr/local/share/certs/ca-root-nss.crt" dnssec_trust_anchors: "/usr/local/etc/unbound/root.key" # add the right path upstream_recursive_servers: ### IPV4 Servers ### ### DNS Privacy DOT Test Servers ### ## 1 - The getdnsapi.net DNS TLS Server A+ ( NLD ) - address_data: 185.49.141.37 - address_data: 2a04:b900:0:100::38 tls_auth_name: "getdnsapi.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q= ## 2 - The Surfnet/Sinodun DNS TLS Servers #3 A+ ( NLD ) - address_data: 145.100.185.18 - address_data: 2001:610:1:40ba:145:100:185:18 tls_port: 853 tls_auth_name: "dnsovertls3.sinodun.com" tls_pubkey_pinset: - digest: "sha256" value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8= ## xx - The The Surfnet/Sinodun DNS TLS Server A ( NLD ) - address_data: 145.100.185.15 - address_data: 2001:610:1:40ba:145:100:185:15 tls_auth_name: "dnsovertls.sinodun.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4= ## xx - The The Surfnet/Sinodun DNS TLS Server #1 A ( NLD ) - address_data: 145.100.185.16 - address_data: 2001:610:1:40ba:145:100:185:16 tls_auth_name: "dnsovertls1.sinodun.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA= ## 3 - The dns.cmrg.net DNS TLS Server A+ ( CAN ) - address_data: 199.58.81.218 - address_data: 2001:470:1c:76d::53 tls_auth_name: "dns.cmrg.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo= ## 4 - The BlahDNS Japan DNS TLS Server A+ ( JPN ) - address_data: 139.162.112.47 - address_data: 2400:8902::f03c:92ff:fe27:344b tls_auth_name: "dot-jp.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: /llFOsnvj7GcXasKrojhZl6nRnnn4D8sRuDUKEdiZzM= ## xx - The BlahDNS German DNS TLS Server A+ ( USA Hosted In DEU ) - address_data: 78.46.244.143 - address_data: 2a01:4f8:c17:ec67::1 tls_auth_name: "dot-de.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: c6xmf1GsYo1IFyxc+CWfjYo+xpSV9i98H7InJTDylsU= ## xx - The BlahDNS Finland DNS TLS Server A+ ( FIN ) - address_data: 95.216.212.177 - address_data: 2a01:4f9:c010:43ce::1 tls_auth_name: "dot-fi.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: EVL610kmcSvN01nzJkkzl94IHiIVvW0PovbB5En2QfU= ## xx - The BlahDNS Singapore DNS TLS Server A+ ( SGP ) - address_data: 192.53.175.149 - address_data: 2400:8901::f03c:92ff:fe27:870a tls_auth_name: "dot-sg.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: B+aX4NBLfDsKlOWf8RM6rjL8yOCF9sZlHQnarDNrrWM= ## xx - The BlahDNS Switzerland DNS TLS Server A+ ( CHE ) - address_data: 45.91.92.121 - address_data: 2a05:9406::175 tls_auth_name: "dot-ch.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: cxti1XR6uW483xAioP3d1ZaoGSy+obY6WaE4fW1A6Nk= ## 5 - 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= ## 6 - The Foundation for Applied Privacy DNS TLS Server #1 A+ ( AUT ) - address_data: 146.255.56.98 - address_data: 2a02:1b8:10:234::2 tls_auth_name: "dot1.applied-privacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: xhQVPE+X85b9LkORuEhxfsxE1X2EbOm8v5ytxCqg5BI= ## 7 - 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: Am37BK5eBKSafYNJupWsoh5pokR3wwJ5zs7xvniF6XE= ## 8 - The dismail.de DNS TLS Server #1 A+ ( DEU ) - address_data: 80.241.218.68 tls_port: 853 tls_auth_name: "fdns1.dismail.de" tls_pubkey_pinset: - digest: "sha256" value: MMi3E2HZr5A5GL+badqe3tzEPCB00+OmApZqJakbqUU= ## xx - The dismail.de DNS TLS Server #2 A+ ( USA ) - address_data: 159.69.114.157 tls_port: 853 tls_auth_name: "fdns2.dismail.de" tls_pubkey_pinset: - digest: "sha256" value: yJYDim2Wb6tbxUB3yA5ElU/FsRZZhyMXye8sXhKEd1w= ## 9 - The Lorraine Data Network DNS TLS Server A+ ( FRA ) - address_data: 80.67.188.188 tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: WaG0kHUS5N/ny0labz85HZg+v+f0b/UQ73IZjFep0nM= ## This certificate is currently expired which ## does not pose any concerns in SPKI mode ## (in practice with Stubby) ## Source : https://ldn-fai.net/serveur-dns-recursif-ouvert/ ## 10 - The ibksturm.synology.me DNS TLS Server A+ ( CHE ) - address_data: 213.196.191.96 tls_auth_name: "ibksturm.synology.me" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: yrMslOFXpWeLoNw0YgQk/pA5vl2mqXfBOASYLLeqDxc= ## 11 - The dns.flatuslifir.is DNS TLS Server A+ ( ISL ) - address_data: 46.239.223.80 tls_auth_name: "dns.flatuslifir.is" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: b9sJFKc+wycfm4FHB9ddNopdeKceru+sZk0w5nz4xfQ= ### Publicly Available DOT Test Servers ### ## 12 - 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: ugm6mY2NNKi0I/Q+pofAgx0c31tbcW6xYAImZXr5Oqo= ## 13 - 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: sS2Atff8wMigRVTxmS36FbMaXiCWsxLgD3AOtTA9eeU= ## xx - 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: /jchI7afFvSaVm4DCTksJcPHyK7uvbcwNUtTNNV4Bek= ## 14 - 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= ## xx - 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: /3AxvvuWCQmYQ4/mqHJzPL1rPC7KxaahVPmUkoSVR5A= ## 15 - The Digitale Gesellschaft DNS TLS Server #1 A+ ( CHE ) - address_data: 185.95.218.43 - address_data: 2a05:fc84::43 tls_auth_name: "dns.digitale-gesellschaft.ch" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: sAH7JR5A8WA+hs1ZGXPS/uq3Y1wufBi2wQ8Crk+oR2Q= ## xx - The Digitale Gesellschaft DNS TLS Server #2 A+ ( CHE ) - address_data: 185.95.218.42 - address_data: 2a05:fc84::42 tls_auth_name: "dns.digitale-gesellschaft.ch" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Fpgt86sGjlL4sbgNmd1WX0BYEIEJ7yQk9rp+uQKxI+w= ## 16 - 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: Dn58VD18MLkmmG9wvzvSs30Tu1Rd65igDLpp1odYaAc= # 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_2 # 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 When I get some time - next day or two - I will post a separate Forum entry which lists many more DNS OVER TLS servers that are publicly available for. However, these are more than enough to get you started. 3 - In order to have OPNsense 21.7.1 use default start up script ( /usr/local/etc/rc.d/stubby.sh ) at boot time it helps 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 755 /etc/rc.conf.d/stubby 4 - Now you must configure your Unbound DNS Server to use Stubby for DNS Over TLS. This is where there has been a ( major ) change to UNBOUND on OPNsense 21.7.1 . The bottom line is that there is no longer any option whatsoever for you to configure UNBOUND Custom Options via OPNsense 21.7.1 WEBGUI. A - See here for the changes - https://bit.ly/3vfx1MT - then scroll down to Advanced Configurations. There you may read about the changes I alluded to earlier. So here is how we go about configuring Unbound/Stubby combination for OPNsense 21.7.1 Some user combine Unbound (as a caching proxy with other features such as DNS Blacklisting) and Stubby (as fully featured TLS forwarder). This is what we are out to achieve. Advanced Configurations Some installations require configuration settings that are not accessible in the UI. To support these, individual configuration files with a .conf extension can be put into the /usr/local/etc/unbound.opnsense.d directory. Now theoretically - you should be able to create the need file by doing the following below : B - # touch /usr/local/etc/unbound.opnsense.d/unbound_srv.conf C - # nano /usr/local/etc/unbound.opnsense.d/unbound_srv.conf enter the following in the new file as detailed below : #################################################### ### Unbound Advanced Configuration server: tls-cert-bundle: "/usr/local/share/certs/ca-root-nss.crt" hide-trustanchor: yes harden-glue: yes harden-dnssec-stripped: yes num-threads: 4 rrset-cache-size: 256m msg-cache-size: 128m so-rcvbuf: 1m val-clean-additional: yes minimal-responses: yes harden-referral-path: yes aggressive-nsec: yes prefetch: yes qname-minimisation: yes qname-minimisation-strict: yes rrset-roundrobin: yes target-fetch-policy: "0 0 0 0 0" max-udp-size: 3072 harden-below-nxdomain: yes ip-ratelimit: 300 ip-ratelimit-factor: 10 incoming-num-tcp: 100 edns-buffer-size: 1472 do-not-query-localhost: no forward-zone: name: "." # Allow all DNS queries forward-addr: [email protected] forward-addr: 0::[email protected] ################################################## *** Note that the file you create must end in .conf in order to be automatically included by the UI generated configuration. Also, Name collisions with plugin code, which use this extension point e. g. dnsbl.conf, may occur. So be sure to use a unique filename. unbound_srv.conf is a unique filename on OPNsense 21.7.1 for sure - trust me. 5 - Now, I have one caveat - when I created this file ( as described above ) via SSH - there was an issue where DNS OVER TLS did not work at all or as it should - the resolvers did not connect. Perhaps the file needs permissions - you can try - chmod 664 /usr/local/etc/unbound.opnsense.d/unbound_srv.conf and see how this works out for you GUARANTEED SOLUTION: What I did was use WINSCP in order to have this setup perform as intended. Use your favorite text editor ( I use EditPad Pro ) and copy Unbound Advanced Configuration above - into a new file labeled - unbound_srv.conf - Save this file to a local directory on your computer. Next, follow the steps below : A - WINSCP into your OPNsense 21.7.1 Firewall via SFTP protocol - SCP will not connect on OPNsense. Make sure to use SFTP protocol. Go into ( open ) the directory below on the right side of WINSCP interface : /usr/local/etc/unbound.opnsense.d/ B - Go into the directory on your computer where you have the unbound_srv.conf file which you previously created and filled out with the Unbound Advanced Configuration. This will be on the left side of WINSCP. C - Drag and Drop unbound_srv.conf ( on the left side of WINSCP ) into the /usr/local/etc/unbound.opnsense.d/unbound_srv.conf ( directory which is open ) on the right side of of WINSCP. Done - close and exit This WINSCP method is GUARANTED to work !!! - I strongly suggest that you choose to make this your preferred Unbound Advanced Configuration option for OPNsense 21.7.1 !!! 6 - Next -Under System > Settings > General Settings A - Set the first DNS Server to 127.0.0.1 with no gateway selected / Make sure that DNS server option B - Allow DNS server list to be overridden by DHCP/PPP on WAN - Is Not I repeat - Is Not Checked ! and DNS server option C - Do not use the DNS Forwarder/Resolver as a DNS server for the firewall Is Not - I repeat - Is Not Checked ! D - Save and Apply Reboot your router or run command # /usr/local/etc/rc.d/stubby.sh restart You are all set up and now. You are now running DNS OVER TLS with GETDNS plus STUBBY ( a fully featured TLS forwarder ) along with an Unbound DNS Caching Server.

We are rewarding users for creating guides for the community - you can get yourself a month free VPN per guide created, some small requirements: 1) Make sure guides are clear and concise. 2) Screenshots preferable. 3) The guide must be unique and not found anywhere else. Any questions let us know. Regards TorGuard

Dear Community, First you all know the drill by now - " The Intro " - a true legend Jackie to all - https://www.youtube.com/watch?v=sBa81YSyshk and the lyrics as always - https://genius.com/Jackie-wilson-baby-workout-lyrics - just for fun - https://www.youtube.com/watch?v=iNLXxDMxe18 - https://genius.com/Chris-montez-lets-dance-lyrics / Surprise Bonus : https://www.youtube.com/watch?v=sIH6s1thcWQ Now with that out of the way. Let's get down to business. I am one of the many who have tried to get WireGuard up and running on pfSense 2.5.2 . Well, I am very pleased to announce that you have come to the right place if you want rock solid WireGuard on pfSense ( finally ). Forget about anything else you may have heard about how to achieve this goal - this is the most simple, direct and effective method you will find. I know - pfsense has WireGuard built in as a package - and there is pfSense-pkg-WireGuard maintained by theonemcdonald. Personally I do not find any of these solutions to be as efficient as the one I will detail here. So - here we go. OK - Here go - let's get down to the business at hand. The first thing we must do is install all the necessary packages for this to work properly. Now you need to know that when you try to view the packages on the FreeBSD servers by way of their url - for example , https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/ - you will get the 403 Forbidden message. There is a remedy / workaround that will allow you to check out exactly what are the most recent package versions for you to install. Go to https://pkgs.org/ - once there - you will see a search box in the upper right hand corner. Just enter the package you wish to find there - then go down to FreeBSD 12 ( the distributions are listed alphabetically - next click on FreeBSD amd64 ( the distro pfSense 2.5.2 is based on ) - finally, go down to the Download section and copy your download url found next to the Binary Package section. 1 - All of the packages that you will need to install are found in the FreeBSD repository. Just install these packages in the order as listed below: A - # pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/wireguard-kmod-0.0.20210606_1.txz B - # pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/bash-5.1.8.txz C - # pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/bash-completion-2.11,2.txz D - # pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/wireguard-tools-1.0.20210914.txz E - # pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/wireguard-go-0.0.20210424,1.txz F - # pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/wireguard-2,1.txz 2 - To begin you need to get your WIREGUARD configuration files from the TORGUARD website. To do so login your TORGUARD account then go to Tools ( along the top of Login Page ). Then select " Config Generator " from the drop down menu. From the top line " VPN Tunnel type: " select WireGuard. Go to the next line - " VPN Server Hostname/IP: " choose your desired location. Enter your TorGuard Username and Password. You also have the option to enter your own Local Private-Key and Local Public-Key if you elect to do so. When all of the fields are complete - click on the " Generate Config " box. Download the file to your desired location. Open the numbered config file with a text editor. Your Config file will be like this - see below : ## all the information below is invalid and fictitious for obvious reasons - use your actual file and valid entries to ensure connection. # TorGuard WireGuard Config [Interface] PrivateKey = 0LyqOOa31kblp0mViH+TfwmBT8PIfWXuT9OUa7cvVmo= ListenPort = 51820 DNS = 1.1.1.1 Address = 100.96.0.141/24 [Peer] PublicKey = fmmIzVG3JL1tjDjTIBpE+C5WQbLGCHsdIqQVodQ7yPM= AllowedIPs = 0.0.0.0/0 Endpoint = 23.10.187.115:1443 PersistentKeepalive = 25 3 - Now I used this guide as the template for my manual installation of WIREGUARD on pfSense see here : https://genneko.github.io/playing-with-bsd/networking/freebsd-wireguard-quicklook/ I will make this simple for you step by step. You may sing and / or hum along as we proceed. A- First - configure WireGuard Client. TorGuard, AzireVPN, VPN.ac, Mullvad, IVPN, are commercial VPN providers which offer LIVE ! WireGuard Services now. I use TorGuard here is a sample file. Keys are dummies - only used for illustrative purposes in this tutorial- Use your real WireGuard configuration file here: Create file by SSH and issue the commands below- A - # touch /usr/local/etc/wireguard/tunwg0.conf B - # nano /usr/local/etc/wireguard/wg0.conf - then enter the contents of your previously downloaded TorGuard WireGuard Config as detailed above. Save and Close. Done with this file. 4 - B - Run command via SSH A - # wg-quick up tunwg0 ( wireguard-go is in package and this action creates wireguard interface ) " tunwg0 " ( tunwgZero ) must be the name of the WireGuard interface otherwise you will have issues You may also run # wireguard-go tunwg0 to create tunwg0 but I prefer the first method mentioned here. 5 - Configure WireGuard Service with rc.d - for automatic startup/shutdown of the tunnel. In order to achieve this there’s already an rc.d script /usr/local/etc/rc.d/wireguard which came with the wireguard package. You need to issue this command : A - # mv /usr/local/etc/rc.d/wireguard /usr/local/etc/rc.d/wireguard.sh / then enter the file - B - # nano /usr/local/etc/rc.d/wireguard.sh Then go to bottom of file - lines 46 and 47 - change : ${wireguard_enable="NO"} to : ${wireguard_enable="YES"} and then add tunwg0 on line 47 : ${wireguard_interfaces=""} to : ${wireguard_interfaces="tunwg0"} ( tunwgZero ) - Save and Close - Make it executable, I run this command - it works for me: C - # chmod 755 /usr/local/etc/rc.d/wireguard.sh - Done with this file. 6- In order to have OPNsense use default start up script ( /usr/local/etc/rc.d/wireguard.sh ) at boot time it helps to create a boot time start up script for it in /etc/rc.conf.d/. Not to prolong this - do the following : A - # nano /etc/rc.conf.d/wireguard - in the new file enter the following two lines: wireguard_enable="YES" wireguard_bootup_run="/usr/local/etc/rc.d/wireguard.sh" Save and Close - Make it executable (tunwg0) B - # chmod 755 /etc/rc.conf.d/wireguard / Done with this file. 7 - A - Now head to pfSense WEBGUI in order to configure Wireguard Interface ( created earlier ) and FireWall Rule. First, go along top menu - go to Interfaces > Assignments -choose tunwg0 interface from drop down menu. Click on the + Add Button. The selection will be listed as opt1, opt2 are some similar name depending on the number of your pre-configured lan interfaces. Click underneath opt2 ( in my case ) - then when the page opens up - Enable the new interface. Name the new interface - in my case " WIRE " . DO NOTHING ELSE HERE ! Save and Apply - Done with this phase. B - Second - Firewall Rule - go to Firewall > NAT > Outbound > Once on this Landing Page put a Dot in radio button Hybrid outbound NAT rule generation - Click on Save - Do Not - Repeat Do Not Click Save and Apply At This Time - Instead Click on Add Square with Up Arrow (underneath Mappings ). On the page which opens change Interface from WAN in drop down menu to your Wireguard ( tunwg0 ) Interface which you created and labeled previously - in this example " WIRE " . Next - Change " Address Family " to IPV4 - " Protocol " to " Any " - " Source " to " Any " - " Destination " to " Any " " Translation Address " to " Interface Address " - Lastly enter "Description " in my case " Made For Wire " now Click " Save " at bottom of page. Finally click " Save and Apply " at the top of the page. Your WireGuard Client is now installed and ready - you must enter command # /usr/local/etc/rc.d/wireguard.sh restart in order to start it up. Lastly, issue command # wg show which prints out your WireGuard Connection statistics and configuration. Sample output for wg show below: interface: tunwg0 public key: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA= private key: (hidden) listening port: 51820 peer: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4= endpoint: 159.x.xxx.xxx:xxx allowed ips: 0.0.0.0/0 latest handshake: 1 minute, 46 seconds ago transfer: 3.35 MiB received, 859.23 KiB sent persistent keepalive: every 25 seconds This solution is guaranteed to ensure that WireGuard interface ( tunwg0 ) the ability to survive a reboot When you reboot or reestablish connection - go to Status > Filter Reload - then press Reload Filter Radio Button to get yourself up and running once again.

Dear Community, First you all know the drill by now - " The Intro " - as a peace loving man and in light of the turbulent times we all must endure - here we go without no further ado - Kool and The Gang / https://www.youtube.com/watch?v=JgxWC3iZh7A and the lyrics if you care to sing along - https://genius.com/Kool-and-the-gang-love-and-understanding-lyrics and one of my favorites - The Chambers Brothers - https://www.youtube.com/watch?v=BvCH-6kOAGs - lyrics here : https://genius.com/The-chambers-brothers-love-peace-and-happiness-lyrics This is a new updated guide designed to assist you in installing DNS Privacy DNS OVER TLS on pfSense 2.5.2 . Please disregard and do not use any guides and / or tutorials which predate this one. The setup features getdns and Stubby forwarded to and integrated with Unbound. You may refer to my earlier guide / tutorial here for additional information regarding the benefits of DNS Privacy DNS OVER TLS - see link here - https://bit.ly/3p0AGwX OK - Here go - let's get down to the business at hand. The first thing we must do is install all the necessary packages for this to work properly. Now you need to know that when you try to view the packages on the FreeBSD servers by way of their url - for example , https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/ - you will get the 403 Forbidden message. There is a remedy / workaround that will allow you to check out exactly what are the most recent package versions for you to install. Go to https://pkgs.org/ - once there - you will see a search box in the upper right hand corner. Just enter the package you wish to find there - then go down to FreeBSD 12 ( the distributions are listed alphabetically - next click on FreeBSD amd64 ( the distro pfSense 2.5.2 is based on ) - finally, go down to the Download section and copy your download url found next to the Binary Package section. 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 ( both of these will install from native pfSense 2.5.2 box ) . The following packages must be installed from FreeBSD. C # pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/libev-4.33,1.txz D # pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/libidn-1.35.txz Now - here is where this guide diverges from its' predecessors. There is a new specific iteration of Unbound which pfSense 2.5.2 has installed. The package is called - unbound112-1.12.0_1 . Now if you attempt to add getdns-1.5.2_4.txz package via pkg add url method - see below : ( # pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/getdns-1.5.2_4.txz ) ### this will not work ! the installation will fail and complain that " missing dependency Unbound " is the reason. so here is the solution to that dilemma below : enter the following command E # fetch https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/getdns-1.5.2_4.txz From there you can enter command # ls -a / and you will see that getdns-1.5.2_4.txz package is now in your root directory. Next just enter the command F # pkg install getdns-1.5.2_4.txz follow the prompts answering " yes " to any all. By the way, once this package is successfully installed it must remain in your root directory otherwise DNS OVER TLS will stop working if you remove it for any reason. Now you may proceed as in the usual fashion. 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 755 /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 - Now you must configure Stubby to resolve DNS OVER TLS - A -# nano /usr/local/etc/stubby/stubby.yml ################################################################################ ######################## STUBBY YAML CONFIG FILE ############################### ################################################################################ # This is a yaml version of the stubby configuration file (it replaces the # json based stubby.conf file used in earlier versions of getdns/stubby). # # For more information see # https://dnsprivacy.org/wiki/display/DP/Configuring+Stubby # resolution_type: GETDNS_RESOLUTION_STUB dns_transport_list: - GETDNS_TRANSPORT_TLS tls_authentication: GETDNS_AUTHENTICATION_REQUIRED tls_query_padding_blocksize: 128 edns_client_subnet_private : 1 idle_timeout: 9000 listen_addresses: - [email protected] - 0::[email protected] tls_connection_retries: 5 tls_backoff_time: 900 timeout: 2000 round_robin_upstreams: 1 tls_ca_file: "/usr/local/share/certs/ca-root-nss.crt" dnssec_trust_anchors: "/usr/local/etc/unbound/root.key" # add the right path upstream_recursive_servers: ### IPV4 Servers ### ### DNS Privacy DOT Test Servers ### ## 1 - The getdnsapi.net DNS TLS Server A+ ( NLD ) - address_data: 185.49.141.37 - address_data: 2a04:b900:0:100::38 tls_auth_name: "getdnsapi.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q= ## 2 - The Surfnet/Sinodun DNS TLS Servers #3 A+ ( NLD ) - address_data: 145.100.185.18 - address_data: 2001:610:1:40ba:145:100:185:18 tls_port: 853 tls_auth_name: "dnsovertls3.sinodun.com" tls_pubkey_pinset: - digest: "sha256" value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8= ## xx - The The Surfnet/Sinodun DNS TLS Server A ( NLD ) - address_data: 145.100.185.15 - address_data: 2001:610:1:40ba:145:100:185:15 tls_auth_name: "dnsovertls.sinodun.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4= ## xx - The The Surfnet/Sinodun DNS TLS Server #1 A ( NLD ) - address_data: 145.100.185.16 - address_data: 2001:610:1:40ba:145:100:185:16 tls_auth_name: "dnsovertls1.sinodun.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA= ## 3 - The dns.cmrg.net DNS TLS Server A+ ( CAN ) - address_data: 199.58.81.218 - address_data: 2001:470:1c:76d::53 tls_auth_name: "dns.cmrg.net" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo= ## 4 - The BlahDNS Japan DNS TLS Server A+ ( JPN ) - address_data: 139.162.112.47 - address_data: 2400:8902::f03c:92ff:fe27:344b tls_auth_name: "dot-jp.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: /llFOsnvj7GcXasKrojhZl6nRnnn4D8sRuDUKEdiZzM= ## xx - The BlahDNS German DNS TLS Server A+ ( USA Hosted In DEU ) - address_data: 78.46.244.143 - address_data: 2a01:4f8:c17:ec67::1 tls_auth_name: "dot-de.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: c6xmf1GsYo1IFyxc+CWfjYo+xpSV9i98H7InJTDylsU= ## xx - The BlahDNS Finland DNS TLS Server A+ ( FIN ) - address_data: 95.216.212.177 - address_data: 2a01:4f9:c010:43ce::1 tls_auth_name: "dot-fi.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: EVL610kmcSvN01nzJkkzl94IHiIVvW0PovbB5En2QfU= ## xx - The BlahDNS Singapore DNS TLS Server A+ ( SGP ) - address_data: 192.53.175.149 - address_data: 2400:8901::f03c:92ff:fe27:870a tls_auth_name: "dot-sg.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: B+aX4NBLfDsKlOWf8RM6rjL8yOCF9sZlHQnarDNrrWM= ## xx - The BlahDNS Switzerland DNS TLS Server A+ ( CHE ) - address_data: 45.91.92.121 - address_data: 2a05:9406::175 tls_auth_name: "dot-ch.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: cxti1XR6uW483xAioP3d1ZaoGSy+obY6WaE4fW1A6Nk= ## 5 - 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= ## 6 - The Foundation for Applied Privacy DNS TLS Server #1 A+ ( AUT ) - address_data: 146.255.56.98 - address_data: 2a02:1b8:10:234::2 tls_auth_name: "dot1.applied-privacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: xhQVPE+X85b9LkORuEhxfsxE1X2EbOm8v5ytxCqg5BI= ## 7 - 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: Am37BK5eBKSafYNJupWsoh5pokR3wwJ5zs7xvniF6XE= ## 8 - The dismail.de DNS TLS Server #1 A+ ( DEU ) - address_data: 80.241.218.68 tls_port: 853 tls_auth_name: "fdns1.dismail.de" tls_pubkey_pinset: - digest: "sha256" value: MMi3E2HZr5A5GL+badqe3tzEPCB00+OmApZqJakbqUU= ## xx - The dismail.de DNS TLS Server #2 A+ ( USA ) - address_data: 159.69.114.157 tls_port: 853 tls_auth_name: "fdns2.dismail.de" tls_pubkey_pinset: - digest: "sha256" value: yJYDim2Wb6tbxUB3yA5ElU/FsRZZhyMXye8sXhKEd1w= ## 9 - The Lorraine Data Network DNS TLS Server A+ ( FRA ) - address_data: 80.67.188.188 tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: WaG0kHUS5N/ny0labz85HZg+v+f0b/UQ73IZjFep0nM= ## This certificate is currently expired which ## does not pose any concerns in SPKI mode ## (in practice with Stubby) ## Source : https://ldn-fai.net/serveur-dns-recursif-ouvert/ ## 10 - The ibksturm.synology.me DNS TLS Server A+ ( CHE ) - address_data: 213.196.191.96 tls_auth_name: "ibksturm.synology.me" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: yrMslOFXpWeLoNw0YgQk/pA5vl2mqXfBOASYLLeqDxc= ## 11 - The dns.flatuslifir.is DNS TLS Server A+ ( ISL ) - address_data: 46.239.223.80 tls_auth_name: "dns.flatuslifir.is" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: b9sJFKc+wycfm4FHB9ddNopdeKceru+sZk0w5nz4xfQ= ### Publicly Available DOT Test Servers ### ## 12 - 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: ugm6mY2NNKi0I/Q+pofAgx0c31tbcW6xYAImZXr5Oqo= ## 13 - 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: sS2Atff8wMigRVTxmS36FbMaXiCWsxLgD3AOtTA9eeU= ## xx - 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: /jchI7afFvSaVm4DCTksJcPHyK7uvbcwNUtTNNV4Bek= ## 14 - 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= ## xx - 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: /3AxvvuWCQmYQ4/mqHJzPL1rPC7KxaahVPmUkoSVR5A= ## 15 - The Digitale Gesellschaft DNS TLS Server #1 A+ ( CHE ) - address_data: 185.95.218.43 - address_data: 2a05:fc84::43 tls_auth_name: "dns.digitale-gesellschaft.ch" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: sAH7JR5A8WA+hs1ZGXPS/uq3Y1wufBi2wQ8Crk+oR2Q= ## xx - The Digitale Gesellschaft DNS TLS Server #2 A+ ( CHE ) - address_data: 185.95.218.42 - address_data: 2a05:fc84::42 tls_auth_name: "dns.digitale-gesellschaft.ch" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: Fpgt86sGjlL4sbgNmd1WX0BYEIEJ7yQk9rp+uQKxI+w= ## 16 - 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: Dn58VD18MLkmmG9wvzvSs30Tu1Rd65igDLpp1odYaAc= # 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_2 # 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 When I get some time - next day or two - I will post a separate Forum entry which lists many more DNS OVER TLS servers that are publicly available for all. However, these are more than enough to get you started. 4 - In order to have pfSense 2.5.2 use default start up script ( /usr/local/etc/rc.d/stubby.sh ) at boot time it helps 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 755 /etc/rc.conf.d/stubby 5- Now you must configure your Unbound DNS Server to use Stubby for DNS Over TLS. Go to Services > DNS RESOLVER > General Settings > Display Custom Options In the Custom options Box - enter the following below : server: do-not-query-localhost: no forward-zone: name: "." # Allow all DNS queries forward-addr: [email protected] forward-addr: 0::[email protected] Save and Apply 6 - Next -Under System > General Setup > DNS Server Settings A - Set the first DNS Server to 127.0.0.1 add no other DNS Servers here B - DNS Server Override - make sure this is unchecked C - DNS Resolution Behavior Use local DNS (127.0.0.1), fall back to remote DNS SERVERS (Default) Save and Apply Reboot your router or run command # /usr/local/etc/rc.d/stubby.sh restart You are all set up and now. You are now running DNS OVER TLS with GETDNS plus STUBBY ( a fully featured TLS forwarder ) along with an Unbound DNS Caching Server.

It could have been any number of things that caused it, if it keeps happening then i would suggest opening a support ticket and asking support why your wireguard configs are randomly stopping working. Maybe they will have an idea, They usually respond fairly Fast through the ticket system and are very Pleasant to talk to. It could be any number of things that caused it though Maybe the DNS in your router was causing connection issues... Maybe the server you were connected to was restarted or down temporarily - the list goes on.

Twice lately it has just failed to handshake. I have to go in and generate a new config and then apply it to get the handshake to work. Nothing is changing on my router or network.

This will not tunel all traffic only if you did not install/configure properly wireguard on Netgear. For other clients, see my previous reply.

Did you try at all what I replied previously? I ask, because I believe if you would have tried, some of your questions would be resolved. Your request is unclear. If you want to check iptables, please run man iptables which will show you description, manual and how to use it. You should not rely on somebodies reply about, read the manual. In previous post I said you should make it as simple as possible. Setup 1 is actually better and more simple. WAN router is your ISP's, it supplies with a dhcp server your clients. Putting router then involves that your router does see your local network (ISP modem). If your ISP's router can give your enough IP's and dhcp is configurable, you can use it, but better you use ISP's router only as wan gateway and port forwarding, meaning that you need to switch of dhcp on isp's router. If that is not possible on ISP's router then you can leave it to act as dhcp server. As next you assign your WAN port of your Netgear router to LAN's vlan (meaning it acts as switch port, some would call it now access point if it has lan) and disable WAN interfaces, configure your LAN interface with static IP where gateway is your ISP router's ip. If you can disable DHCP on ISP's router, then setup your dhcp server on netgear to actually supply clients with gateway (3) and dns server/s (6): 3, 192.168.0.1 6, 1.1.1.1,1.0.0.1 Ok, by that it is clear, your ISP router in local network has ip 192.168.0.1 (for vpn lets use 172.16.42.1/24), dhcp server is your netgear. By that all devices are in same network which makes further discussion simpler, later then you can put as many firewalls as you want if when you have a working setup. As next, you decide that your ubuntu server connects to torguard, beside the configurations on ubuntu which are required assuming you got it all, you add to this server peers interface - torguard server - two IP addresses, one which you get from TorGuard (10.xx) and another on which this interface acts as server (172.16.42.100/24) peer1 - Torguard Endpoint peer2 - netgear router (192.168.0.2) (lets say in VPN you want to allow only one ip, 172.16.42.2/32) peer3 - your pc (192.168.0.3) (in vpn you give lets say 172.16.42.3/32) All of devices connected to lan/wlan receive already correct settings from dhcp and can reach each other as well as their internet is working. Ok, so, on your pc, lets as you actually want to route all traffic over your ubuntu server, in your PC config youw will use then in: peer1 ubuntu server - AllowedIps 0.0.0.0/0 thats it, however, you still can add also your netgear router as a peer too: peer2 your pc - AllowedIps 172.16.42.2/32 On your router, you do the same. Now you have a working local network with working vpn network, considered you forward also wireguard's listen port to ubuntu server. In this configuration only those devices which are connected over vpn use torguard, every another device uses clearnet address. In this case: 1. Your roku box uses normal connection and has normal ip addresses behind your ISP's router, just check if you need additionaly to use only ISP's dns for streaming, if not, then great, if yes, then set those on roku box directly. 2. Your ubuntu server is in VPN, considering you have also proper configuration in wireguard (normally ifup/down) it can also reach local devices locally as well as over vpn, you asked for example, here would be one where torguard's port forwarding works too: PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; iptables -t nat -A POSTROUTING -o %i -j MASQUERADE; iptables -A FORWARD -o %i -j ACCEPT PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; iptables -t nat -D POSTROUTING -o %i -j MASQUERADE; iptables -D FORWARD -o %i -j ACCEPT 3. Your netgear device uses VPN (torguard) over ubuntu server but as it is configured as a switch, all devices connected over LAN/WLAN would not be using wireguard, which is exactly what you want on this point. Ok, on that point we have now working vpn server, we have configured peers and we have it all in same network. Here it is then up to you to experiment, not to me to try to guess your configs, there are endless configuration possibilities. However, lets say you decide on this point, that you actually do want roku box to go over torguard but for streaming services it should use normal connection over your ISP. Then do not setup your router as switch which I described above, then your netgear will have wan port and all devices connected to it would use its wan connection, meaning that all devices connected to your Netgear would be in VPN. This would be now something which you describe as SET UP2. In SET UP2 it is just about configuration of your Netgear router where you can now set new vlan for vpn and add rules on dns level and to filter your ISP's streaming service Ips/domains and set them to go over another WAN which is your VPN interface. If you already do know IP's and do not want to deal with dns, then use multiwan or try calculating proper ip route/s and those have to be added to Wireguard configuration (PreUp/PreDown). All in all, whatever path you choose, you still need to know exactly which IP's you do want to route/exclude etc... . If you do not know it, go for setup 1 where your netgear router in difference to setup 2 does extend your WLAN.

This thread is very OLD , as far as i know Wireguard Configs Do Not Expire anymore. They changed it months ago. I been running Wireguard In my Router for Months and it's still connected and working for me.

I wonder if this explains why my wireguard tunnels keep failing, for no reason at all.

No dude! You ARE the man! Write as much as you want! Again here is my config: SET UP 1 WAN (MODEM) => ROUTER (NETGEAR) => PC + ANDROID + Roku + UBUNTU SERVER 20.04 This configuration will not tunnel all traffic. I do not have an option to install a client on every pc or Android device. Test config: SET UP 2 WAN => Ubuntu Server 20.04 => ROUTER (NETGEAR) => PC + ANDROID + Roku So my configuration I have tested so far allows the Ubuntu Server before the router acting as a primary gateway and tunnels all traffic to Torguard from the router etc. The router in this mode ACTS ONLY AS A SWITCH AND AP with DHCP done via Ubuntu Server 20.04 Problem is my ISP provider will not allow streaming Live TV outside the WAN assigned IP designated by Mac Address on my own modem. One solution: FROM SET UP 1 Set iptables to forward all traffic to the Ubuntu Server from the main router with the only exception being the devices that I need to make exceptions for. I don't have any examples or experience in this. If you could help provide me with some iptables which would forward ALL network traffic to an acting VPN tunnel behind the same router let me know.

That is why I wrote that for devices where wireguard can not be installed you should use use your router. That is not a problem at all, you kinda want to use it as a gateway, you still need a rouoter from your ISP, considering that ISP router is your wan/gateway. Normally, for such setups one can configure their ISP routers into route mode instead of switch mode, then your private router within your network could have outer IP. All in all, all this has not much to do with wireguard but with your design of a network. I think it is better to keep things simple and build up on that. So far I understand, roku is one of devices which you do not want to go over vpn because then your TV subscription would stop working. Roku is probably also a device where you do not install VPN. Now if you want to actually define routing and rules, best is on a router meant for it as everything that you need is given and is a device which you can leave on. If my understanding is correct, then I already replied to you how you easily can achieve that, there are many ways, as example, one them would be to create vlan and interface for second local network, where in one no vpn is used as wan and in another vpn is used. Probably more simple solution would be to setup a local proxy where you need to define which addresses belong to the service which your provider offers, only those should then not go over vpn. In this case all your roku communication would go over proxy which is on your local router and router decides then what and where can go. You mentioned ddwrt, yes, there you can set it up too, but I am not using it and would not like to give advices on ddwrt, but on openwrt you would have additional option which is called mwan (multiwan), you can define which wan should be used for as example specific local ip,subnet etc.. As you see, there are many ways how you can achieve from what I at least believe you are trying to achieve About solution, it depends on what you have, I in general tend to actually use own router for networking things, like dhcp, dns etc. For things like proxy, socks, vpn, it is much cheaper something like rpi4 than some $ 300 router with much less cpu power/ram. The way how you set it up with ubuntu server in front, this is ok but only if does not act as a gateway to the network, but offers just wireguard server (in this case your ubuntu server has also no access to local network as it is behind your routers firewall). Because if lets say TorGuard's server goes offline or your ubuntu server hangs, it would affect only vpn peers, but not the whole network. you can do it easily, specify second IP of your interface with /24 range. As example, torguards vpn outer IP: 123.123.123.123 (Endpoint), where wireguard assigns to you some 10.x.x.x/32 address (/32 means only one). This IP you have to enter in your interface configuration under address, lets say it is 10.1.2.3/32. This is address which you need to use to establish connection to Torguard server. However, as you do not get a free range of ip's but only one, you actually should use another address range for your private network and no, no second wireguard config/interface is required. So, on ubuntu your interface looks then something like this [Interface] SaveConfig = false PrivateKey = YourPrivkey # Torguard VPN Ip which you get from Torguard Address = 10.1.2.3/32 ... Now you want it to actually act also as a server (it that terminology is at all correct for wireguard), for this you add second line, lets say we choose from some range that is not used, your router probably uses 192.x.x.x, Torguard VPN 10.x.x.x, you can use here 172.16.x.x which is also kinda private range: [Interface] SaveConfig = false PrivateKey = YourPrivkey # Torguard VPN Ip which you get from Torguard Address = 10.1.2.3/32 # Ip range for your own vpn server for peers connecting to this device Address = 172.168.42.1/24 ... Then all your peers connecting to that server (internet/intranet) need to use 172.168.42.x/32 in their interfaces (of course this can go endless as each peer can be also a server at the same time). This way you can stay connected over vpn always, even if you do not want to VPN for your internet connection, then change allowed ip's according to that adding only the ip's which you need to reach into allowed ip's. To prevent writting wall of text, I stop here as I believe that your question of how to configure your ubuntu server is replied, in short, you just need to configure wireguard interface and add your peers, thats all.

The problem is: 1 - I cannot install wireguard on all devices which need VPN. 2 - I would like to make the incoming WAN behind the TorGuard VPN using the WireGuard on Ubuntu Server 20.04. 3 - Putting my WAN behind the VPN makes the Roku boxes lose XFinity Stream access (paid TV subscription service through my ISP). So the solutions that would work for me: 1 - Set up a traditional router behind the WAN and set up the Ubuntu Server 20.04 box with Wireguard next to the default gateway ip (192.168.1.1 would be the router and 192.168.1.2 would be the Ubuntu Server). In doing that I would have to Forward ALL traffic to the Ubuntu Server and then tunnel through Wireguard which means have some vlan forwarding rules or something similar. 2 - Find some way to configure the "wireguard peer" connection from Ubuntu Server 20.04 to TorGuard's 10G with an exception for only specific IP's or MAC Addresses.

This may be obvious, and something you've already tried. But when this error happens to me after fresh install, I simply close TG and reopen and attempt to connect again and it works. Sometimes(and hopefully) the simplest action is the solution.

Fail After Fresh Install. ?????? Now what?

I think the Nvidia Shield is different to mobile Android

I'm using the correct Username and password and reset to default and still get this error.

On Android? You should see a little key icon in the status bar that indicates you're connected to a VPN (it won't be there otherwise).

thank u admins for all the hard work u do keep up the great work have a great day🙂

If taken that strict, then I must admit you are wrong. The question is when IPv6 support is coming, but not for which product, therefore you are wrong because 10Gbit servers have ipv6, meaning that you can at least use socks with ipv6 support: It means there is already ipv6 support for socks (maybe proxy too as well it might be some testservers around too). For further info you probably should ask support by dropping them email or creating a ticket because this specific question seems to be in work as we can see it working on some servers. Test servers which you use if they support ipv6, with wireguard you still can setup your interface to actually route all ipv4 traffic over torguards ipv4 peer (vpn) and ipv6 goes over another peer (local) which uses sock5 with ipv6 support. WIth that workaround you get ipv6 support even if your own network/isp does not provide you with one ipv6, the only which would not work over ipv6 would be port forwarding, however, if you have ipv6 from your provider then using it for port forwarding would work just fine too.

They refuse to answer since february, just go with the assumption that there will be no IPv6 any time soon.