• Posts

  • Joined

  • Last visited


  • Gender
  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Cassidy's Achievements


Noob (1/14)



  1. 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
  2. A /24 CIDR suffix will not cover the address you specified. If your address is, for instance, it's not included in that subnet mask. basically means 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 subnet. That covers anything in 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 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 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 🤔
  3. 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.
  4. 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.
  5. 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.
  6. 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 '' 2020-09-11 17:07:01.348445 [INFO] VPN_REMOTE defined as '' 2020-09-11 17:07:01.387536 [INFO] VPN_PORT defined as '51820'
  7. I find that hard to believe, that error specifically refers to a syntax error on the Endpoint line...
  8. Try addinng "/32" to the end of your "Address" line and changing "Remote" to "Endpoint".
  9. 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.
  10. 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
  11. 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
  12. 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.
  13. 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!).
  14. 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
  15. 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, then this would be 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.