Cassidy

Ahh, that's really interesting! I opened a PR to test to see if the interface exists, if you care about getting rid of that warning. Seems like an easy fix

A /24 CIDR suffix will not cover the address you specified. If your address is 192.168.100.123, for instance, it's not included in that subnet mask. 192.168.1.0/24 basically means 192.168.1.xxx. The third byte in the subnet mask is set to 1, so you'd need to increase the mask size if you want to cover more addresses. Sorry if that's confusing; I won't go into more detail on that to keep us on topic, but I'm happy to explain if you're curious. There's also plenty of google-able info if you want to know more, but for the time being I suggest just using a 192.168.0.0/16 subnet. That covers anything in 192.168.xxx.xxx. Any IP address starting in 192.168 can't be public anyways, so unless you're trying to block it off from another local network (in which case you should be using a firewall anyway), a /16 should be fine. Also, if you're using stack deploy or docker-compose, make sure you don't have any conflicting variables set in Portainer. Portainer likes to use its own interface/syntax for setting that stuff, so it's easy to get conflicting dupes. (I still like it better than UnRAID's silly Docker menu though, haha) Just as an aside to @Dyon, I couldn't help noticing these log lines: Warning: `/config/wireguard/wg0.conf' is world accessible, wg-quick: `wg0' is not a WireGuard interface, 2021-01-18 17:39:22.882714 WireGuard is down already, Warning: `/config/wireguard/wg0.conf' is world accessible, [#] ip link add wg0 type wireguard, [#] wg setconf wg0 /dev/fd/63, [#] ip -4 address add 10.10.6.5/19 dev wg0, [#] ip link set mtu 1420 up dev wg0, [#] resolvconf -a wg0 -m 0 -x, [#] wg set wg0 fwmark 51820, [#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820, [#] ip -4 rule add not fwmark 51820 table 51820, [#] ip -4 rule add table main suppress_prefixlength 0, [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1, [#] iptables-restore -n, It's kind of odd that the wg0 interface is being called upon before wg-quick can create it -- do you know what might be trying that? It doesn't seem to be breaking anything, but I find it odd that it's happening so early 🤔

I use Mullvad - if you'd like to post your Mullvad Wireguard config I don't mind taking a look. For some reason Mullvad does some silly config stuff but it's an easy fix and isn't the plugin author's fault.

Another alternative would be to simply parse through the file and sanitize it ahead of time - simply remove all spaces, then replace the first "=" on each line with " = ". That should be relatively easy with sed or awk, depending on preference (as long as it's only the first "=", it shouldn't break keys). You would also want to skip any lines that start with "#", to avoid turning comments into gibberish. That way, you'd also be forcing broken Wireguard config files into the correct TOML format! I don't know if you want to make the script able to edit the files though - that could introduce other issues.

Wow, what an odd bug! I wonder if it might be a better idea to use some sort of TOML-reading library rather than a sed command? That way it would be less likely to have formatting discrepancies. Technically, it is proper practice in TOML to do " = " instead of simply "=", but most YAML or TOML parser should overlook that. It might cut down on extra work for you in the long run if you use something like this YAML/TOML parser. This TOML wiki page lists popular parsers/libraries that could be helpful. I imagine you'd probably want to use Shell, Python, Go, or maybe Rust. But hey, if you're fine with just using sed that's OK too! I was just looking for a way to cut down on weird headaches like formatting inconsistency between VPN providers.

That's really odd - I'm having trouble with this one. The only difference between your config file and mine is that I have a DNS set, and I'm using port 51820 on the server instead of 51819. Neither of those should cause an issue, though. The fact that it's missing the Endpoint line for some reason makes me think it's grabbing the wrong file... wg and wg-quick use different syntax so if the file is named incorrectly that could cause an issue. Assuming your file is named wg0.conf, that really shouldn't happen though. I've found this sometimes happens if you have trailing spaces in places where they shouldn't be. For some reason, Wireguard is picking up the 'wg' version rather than the 'wg-quick' version. If it helps at all, this is what it should be logging: 2020-09-11 17:07:01.046734 [INFO] VPN_ENABLED defined as 'yes' 2020-09-11 17:07:01.084589 [INFO] DISABLE_IPV6 is set to '1' 2020-09-11 17:07:01.121571 [INFO] Disabling IPv6 in sysctl 2020-09-11 17:07:01.193294 [INFO] VPN_TYPE defined as 'wireguard' 2020-09-11 17:07:01.254884 [INFO] WireGuard config file is found at /config/wireguard/wg0.conf dos2unix: converting file /config/wireguard/wg0.conf to Unix format... 2020-09-11 17:07:01.308905 [INFO] VPN remote line defined as '66.71.247.202:51820' 2020-09-11 17:07:01.348445 [INFO] VPN_REMOTE defined as '66.71.247.202' 2020-09-11 17:07:01.387536 [INFO] VPN_PORT defined as '51820'

I find that hard to believe, that error specifically refers to a syntax error on the Endpoint line...

Try addinng "/32" to the end of your "Address" line and changing "Remote" to "Endpoint".

Sounds to me like you definitely deleted too much of your config file! If you'd like to post it with your private key redacted, I should be able to spot the error. Even the most minimal Wireguard client config needs an 'Addresses' and 'PrivateKey' line in the [Interface] section and a 'PublicKey', 'Endpoint', and 'AllowedIPs' line in the [Peer] section.

Afraid not. You'll have to generate new keys with Mullvad's online key generator. This goes for all Wireguard VPNs - 1 key pair = 1 address. You can, however, route other dockers through this one but there's not much reason to do so when you can just generate a new set of keys. EDIT: I feel like I glossed over some stuff. What I meant to say by "1 key pair = 1 address" is this: If you connect using the same config file, then you're obviously trying to connect to the same endpoint IP and port. Now, because Wireguard assigns one IP for each incoming tunnel, it needs a different public key for each connected client in order to tell them apart. For instance, if server X receives two connections with identical public keys (Y1 and Y2), how does it know whether to give Y1 or Y2 the designated IP? This is one of the potential shortcomings of the Wireguard protocol, as it's hardcoded into the protocol that more than one client cannot be connected with the same public key at the same time. The benefit to this is that the incoming IP can be literally anything as long as the public key is the same - this enables simple and reliable roaming as long as the server has a static address. So that raises the question: what can you do if you want to have two VMs/containers VPNed? Well, there are a few different options. For one, you can connect to a different server with the same key. For Mullvad, this means you could use (for instance) server 'us6' for one client and server 'us18' for another. This way, while you are using the same key, the same key is never seen on the same server. Another option is to generate another key pair for your second client. This option is the safest and easiest to maintain, although some VPN services limit the number of keys you can have. And, finally, the third option is to route multiple VMs/containers through the same tunnel. This can be done with iptables rules and static routes on the host, or by setting up a separate "VPN" container. I believe someone else already explained how to do that in this thread, but there are actually several different methods to get that result. That's a bit out of scope for this post though haha

I could be wrong about the IPv6 issue, but I use Mullvad and had the exact same issue. I think Mullvad's "no IPv6" issue just puts in a loopback address instead of entirely removing the IPv6 lines, or something like that. Annoying, but thankfully WG conf files are super easy to audit

That error can be caused by a few different issues, but usually it's IPv6 network incompatibility. Try removing any IPv6-related lines from your config file (should be at the end of the 'Address=' line and the 'AllowedIPs=' line.

changing the webui port in the host shouldn't matter, but changing it in the container would certainly keep it from working. If you need it remapped, use docker to do that - e.g. docker container run <...> -p 8080:8081 <...> If you instead remap it in the qBittorrent webui or using its .conf file, it won't be able to pass through the firewall (it also won't get forwarded by docker, since docker is expecting it to be listening on port 8080!).

Darn! I totally misread what they were talking about, haha. That's an interesting site. I assumed they were talking about the qBittorrent WebUI that shows the download queue... Edit: WOW the people in my apartment complex download a LOT of porn

I think UnRAID is a great place to start if you want to get into server administration! It doesn't 'dumb down' any aspects of the process if you want to delve into the terminal, but it also makes the WebUI available if you don't really want to get into the nitty-gritty of some process. Even the WebUI can be a little challenging starting out, but trust me when I say using it will be second nature after a few months. That said, I highly suggest learning the terminal equivalent commands to whatever you're doing in the WebUI - those will work across other systems. Docker, specifically, is very helpful to learn, and can be deployed on almost any hardware. You mentioned that you're using UnRAID for business as well as personal projects, and while I'm sure you've already considered this, please keep in mind that it's quite easy to break the law without realizing it when you're dealing with torrent programs. Make sure to read up on what you're doing and do your legal due diligence, especially if business is involved. When you're talking about Wireguard, I think you're actually talking about 2 different things: - A Wireguard SERVER on your UnRAID server. This accepts connections and allows you to access your internal network from anywhere (if it's configured properly). - A Wireguard CLIENT, located inside of your qBittorrent container. This forwards your traffic to a remote server - this can be your own VPS box OR, in your case, a VPN server. Just to make it clearer, qBittorrent uses several ports but let's just simplify it to two: MGMT (8080, the management WebUI) and TRNT (the torrent downloading interface). MGMT is only accessible over the internal network. You'll use your Wireguard client on your laptop/phone/etc. to VPN into your internal network, and open the MGMT page in your browser. It will only be accessible while you are VPN'd into your internal network. The TRNT interface, on the other hand, routes ALL traffic through a remote VPN. This is a service you pay for, and all your TRNT traffic will move through it. As such, only the packet size, quantity, and the IP of both you and the server will be viewable by your ISP. It's important to understand the difference between the MGMT and TRNT interfaces, because they're treated separately. When you tunnel in using your own Wireguard tunnel, you haven't affected the qBittorrent server at all. You're just treated like you're on the internal network (because you are), and therefore can access the MGMT interface with no problems. Here's the flow of events when you want to download content: 1. You activate your Wireguard VPN client on your remote device. It connects to your UnRAID server, placing you on the internal network. 2. You use your device to open qBittorrent's MGMT interface (if your UnRAID server is 192.168.1.10, then this would be 192.168.1.10:8080). 3. You log in with your qBittorrent WebUI credentials - this page is plain HTTP so it is completely exposed to anyone on your internal network. This means anyone there can read the password as you send it! This is why setting up SSL is usually a good idea, just to be safe. Anyways - 4. You find the magnet link or torrent you want and enter it into qBittorrent WebUI. 5. Once you hit 'start download', qBittorrent reaches out over its TRNT interface. This request is forwarded, over a secure Wireguard tunnel, to your VPN provider. Let's call them ACME. 6. ACME forwards the request on, and keeps the connection open. Any other torrent clients will see you as whatever IP ACME has assigned you for this session. This effectively eliminates the risks of honeypots, unless ACME gets a subpoena! 7. qBittorrent communicates to the other torrent clients and gathers the pieces it needs to assemble the whole requested file, all the while unaware that it's actually being proxied through ACME's servers. 8. Once the torrent is complete and you've seeded all you want to, you remove the file from qBittorrent's WebUI and it closes the TRNT interface. ACME releases the IP address and the Wireguard tunnel is closed. There's no such thing as invisible. All you're doing by using a VPN is making it a bigger pain in the ass for anyone trying to track you. TOR is the way to go if you want to really obscure your traffic, but your bandwidth would take a big hit. In almost every case, a VPN provider is plenty. I was a bit confused by the wording in your last paragraph, so I just want to reiterate: Wireguard is not a VPN provider. It's a protocol that some VPN providers use. Technically, you're your own VPN provider, for remote access to your internal network at least. For the aforementioned TRNT interface, you can choose whatever VPN provider and protocol you want. Some examples: - NordVPN over OpenVPN - Mullvad over Wireguard - PIA over IPSec None of these are going to be huge speed differences. It's mainly about preference (at least, on this scale). The 'VPN provider' is the brand (Nord, PIA, etc.), while the VPN protocol is Wireguard, OpenVPN, or IPSec.

Hi Stephen! There's no shame in being inexperienced - everyone starts somewhere. I'll try to answer your questions in order, but feel free to reach out to me or other community members if you want any more help That depends. All Wireguard does is create an encrypted tunnel between you and a server. Your ISP can still see that UDP packets are being passed, they can see how many, what size, and their destination (the Wireguard server). So in terms of "hiding" - yes, the actual data being transferred is not visible to your ISP. They will still know you're using a VPN, however, as Wireguard servers always have static IPs and are relatively easy to track. Past the Wireguard server, many VPN providers do some funky routing and IP assignment randomization to try and protect your privacy. You'll want to contact your VPN provider or check their FAQ page if you have any privacy concerns. Just to reiterate: Wireguard is NOT a VPN service. It is a low-level routing protocol that a few VPN providers utilize. It is marginally more efficient and secure than OpenVPN, and the server-side configuration is a breeze. This makes it ideal for a setup in which you have to handle both ends (client and server), but it may not be necessary for a simple client-only VPN solution. Again, contact your VPN provider and make sure you understand what you're paying for. Most VPN providers don't even support Wireguard yet; NordVPN doesn't give out their configs, and PIA doesn't do it officially AFAIK. Those two have also had some scandals in the last year, so I suggest doing your own research. ---------- I believe you're mixing up "websites" and internal sites. A website is a page server on the internet (web) which is accessible publicly. qBittorrent (and most other torrent clients) have what's called a WebUI - an HTTP interface for changing settings and the such. UnRAID's WebUI is an example of that (tower.local or your server's IP IIRC). Normally you would NOT want to expose these to the web, at least not without placing them behind a reverse proxy and Fail2Ban or a similar brute force mitigation service. So, qBittorrent's WebUI is not accessible to people outside your network, unless you intentionally allow it; you may this as destination NAT or "port forwarding". Now, inside of UnRAID, you can decide how the WebUI is accessed. Hell, you could disable it entirely (although then you could only monitor/use qBittorrent through its API). I believe port 8080 is the default for qBittorrent, so you would open [UnRAIDIP]:8080 in your browser to change settings and download torrents. The qBittorrent WebUI also includes optional password protection and SSL encryption, although they are disabled by default - this specific Docker template, qBittorrentvpn, has an environment variable you must set to enable SSL encryption. TL;DR: qBittorrent is exposed to your internal network. If you don't like that, turn on SSL encryption or use a terminal-based application like transmission-cli. No one outside your network can access the qBittorrent WebUI unless you expose it intentionally via NAT/"port forwarding" or have some seriously bad firewall rules. ---------- I'm not sure I understand. If you have a Wireguard server running on your UnRAID machine or anywhere else on your internal network (and you have the incoming port - 51820 by default, I believe - NATed to the correct server), then yes, you can connect to your internal network from anywhere in the world and have access to qBittorrent's WebUI. This is more secure than exposing the WebUI to the internet, by far. The more applications you can keep internal and only access while VPN'd in, the better. I can't really understand what this has to do with OpenVPN, so you may need to clarify if this didn't answer your question ---------- They're all just utilizing the same BitTorrent protocol, so there shouldn't be any significant difference in speed. Which one you choose depends heavily on preference, I would just suggest avoiding uTorrent as they've been caught selling user data in the past (at least, I think that's the one!). Deluge is very old and has good community support, but it can be a bit of a pain to set up. Transmission is less fully-featured, but if you hook it into Radarr/Sonarr/Lidarr it's just as capable. qBittorrent is my personal favorite and has a lot of useful features, but just like Deluge you'll want to do some Google-Fu and make sure you know what you're doing when you enable/disable settings. Certain settings can affect the security and privacy you'll be risking. Speed of the actual downloads will be affected by a myriad of different variables. These include (but are not limited to): - Number of seeders the specific torrent has (and their individual bandwidths) - Bandwidth between you and your VPN provider - Whether your VPN provider's IP has been blacklisted on any trackers (very common with large VPN providers) - What discovery protocols you have enabled on your BitTorrent client Those are just a few of the major ones. Generally if you're having a speed issue, it'll be a problem with your VPN provider or your client configuration, not with the client itself or whatever VPN protocol you decide to use. I know this got a little lengthy, but I hope it helps! I'll hang around for a bit in case you have any more questions. Full disclosure: I've been running enterprise servers (and home UnRAID servers) for many years but I'm far from an expert. There are some absolutely brilliant people here and over on the Level1Techs forums if you can't get the help you need here

Thanks so much! this saves me (and probably some others) some trouble. Thanks for taking the time to make that change, and to put this whole project together in the first place!

I might be able to help with this! Wireguard config files are very simple but it's easy to mess up the syntax if you aren't used to them. Can you post your config file with all keys and IPs censored?

Interesting! That was exactly what I was talking about, but I didn't realize someone already had an image prebuilt! From that page: That's gonna be your answer. To be honest, I don't know that much about UnRAID's Docker implementation. I use swarm/compose for everything, so I'm much more used to that syntax. There's an example docker-compose.yml file on the creator's GitHub, so that would be a good start. You'll have to translate it into the odd fields UnRAID uses, however. For instance, the username field: In compose syntax: environment: - USER = "username" In run/create syntax: docker run -e USER="username" thrnz/docker-wireguard-pia In UnRAID's syntax: Config Type: Variable Name: USER Key: USER Value: username I'm not really sure how the non-environment variables translate to UnRAID. There's probably a guide on it somewhere, but it'll be a little tricky. That compose file is clearly designed for deployment as a stack, but maybe someone here can figure out a way to simplify it for use in UnRAID? Seems like a lot of work for a rather nice use-case though. At some point it'll just be easier to deploy it as a stack and be done with it. If you want to try and convert it to UnRAID's syntax, I should be able to help - but as I said I'm not super experienced with UnRAID's docker syntax. Someone else here might be able to create a template much faster than me. I'd just suggest that if someone decides to embark on that process, they might as well make it a general use Wireguard proxy that can take more than just PIA credentials. Just a suggestion, though!

PIA is designed to operate through their own proprietary app (same as Nord). They don't offer any official way to connect via vanilla Wireguard, as mentioned in this reddit post. I saw some people discussing ways to rip Wireguard config files from the PIA app, but that seems pretty far out of scope for a simple docker container... Maybe it would work better for you to set up a VPN router container that would handle PIA and then route your other containers through it? That's the only way I can think of that would allow you to take advantage of a container workflow while also ensuring support and all the other features provided by PIA (dynamic server failover, etc.)

A python branch would be great and pretty easy to set up. Thanks for your interest!

Would you consider adding `apt install -y python3` into the RUN command for the Dockerfile? I don't know if you consider it out of scope for this specific application, but it's required for search to work properly. It's an easy fix but it would probably significantly increase the container size. Up to you, I'm fine with using my own Dockerfile. Just thought others might like it. Example of error when python is not installed: Error: (I) 2020-08-21T12:23:58 - Plugin jackett is not supported. (I) 2020-08-21T12:23:58 - Python not detected QIODevice::read (QProcess): device not open Could not parse Nova search engine capabilities, msg: QIODevice::read (QProcess): device not open