Xaero

So I had everything working. Updated only the plugin and now only my first peer can ever get a handshake. And even though I get a handshake - the WebUI, no LAN or server hosted content is accessible, and neither is the internet. I just want a relatively easy to use VPN for myself and the people I have accessing it and I cannot figure out what I'm doing wrong now. I didn't touch any configuration other than updating wireguard from the original release to the one from November. Not sure what all should be posted so here's the censored wireguard config(s) for the half-working peer: /etc/wireguard/wg0.conf: [Interface] #include=/webGui/include/update.wireguard.php #file=/etc/wireguard/wg0.conf #cfg=/etc/wireguard/wg0.cfg #cmd=update #name=Blackhole #vtun=wg0 #wg=active #subnets1=192.168.1.74, 10.253.0.1 #subnets2=192.168.1.0/24, 10.253.0.1 #shared1=192.168.1.74, 10.253.0.0/24 #shared2=192.168.1.0/24, 10.253.0.0/24 #internet=192.168.1.74:51820 #Home PrivateKey= Address=10.253.0.1 ListenPort=51820 PostUp=iptables -t nat -A POSTROUTING -s 10.253.0.0/24 -o br0 -j MASQUERADE PostUp=logger -t wireguard 'Tunnel WireGuard-wg0 started' PostDown=iptables -t nat -D POSTROUTING -s 10.253.0.0/24 -o br0 -j MASQUERADE PostDown=logger -t wireguard 'Tunnel WireGuard-wg0 stopped' [Peer] # PublicKey= PresharedKey= AllowedIPs=10.253.0.0/24, 192.168.1.74, 192.168.1.254 /etc/wireguard/peers/etc/wireguard/peers/peer-Blackhole-wg0-1.conf: [Interface] # PrivateKey= Address=10.253.0.2/32 DNS=192.168.1.254 [Peer] #Home PresharedKey= PublicKey= Endpoint=dyndns:51820 AllowedIPs=192.168.1.0/24, 10.253.0.0/24 I feel like an IPTables rule is missing, but I don't know enough to figure out what it is. My reasoning is that the result of attempting to ping the DNS server (192.168.1.254) results in a Destination Host Unreachable from 10.253.0.1 (the unraid server) The handshake completes so I know the peer keys and endpoints are right, something on the routing side is wrong.

Oh man. I thought something seemed off just hadn't looked into it yet as I noticed a bunch of new content didn't seem to be working properly with tvdb. Phew.

That also didn't exist until well after this thread was made.

I'll note a few things here; Switching to using Docker-Compose instead of Docker Run solves this automatically. Docker-compose supports always using container or service network types by name. It will just resolve the name to the container ID on startup from the docker-compose.yml file. Docker compose also comes with the benefit of health checks and health even based management (vpn docker goes down? automatically stop all dependent dockers. Comes back up? Starts them back up.) Seems worth looking into; obviously not an easy to implement change as the current docker profile system has been a product of years of development. Would be nice to move to a more standard docker implement like compose though.

I believe netbios would work with a netbios over tcp implementation. By default; probably not.

I think the latter can be achieved with one more routing rule; I just haven't sat down to figure it out.

You would want to use the remote tunnel option so that 0.0.0.0/24 is the AllowedIPs for the tunnel. This should capture all traffic from the remote device and send it through the DNS (your local router) You would want the DNS set to PiHole to get PiHole to filter it.

Needs to go on the client side peer config Add to the list with AllowedIPs=1.2.3.4/32, 5.6.7.8/32 Once set in the client config you do have to stop/start the wireguard server. Make sure the config on the client is updated as well (changing it on the server doesn't change it on the device(s) that have that peer config loaded, so you'd have to reload it onto those devices. Once it's loaded onto the devices, the server has been restarted and you connect, try pinging the IP you are trying to access. It should at least ping if it's routable.

In the [Peer] section for the PEER configuration file that you want to have access to 10.0.2.3 make sure that 10.0.2.3/32 is in the list of AllowedIPs. If it's not, the tunnel won't send traffic to it.

The DNS server on my local lan, in this case my ISP provided cable modem gateway. Though eventually that will be replaced with OPNSense, now that I've tested everything works that way. Also, do note that you need to edit the peer configuration files manually in /etc/wireguard/peers Afterwards you can regenerate the QR code using my instructions above, so that you can provide users with a QR code or the ZIP.

FYI, I was able to get this working properly manually with only the following data for all profile types: DNS=<Local-IP> in the [Interface] section of the peer config. <Local-IP>/32 included in the AllowedIPs= of the [Peer] section of the peer config. A single DNS field and some rudimentary logic should sort whether or not the DNS is already included in the range. From there I manually regenerated the QR codes and moved on. Of course I can't touch those peers in the GUI now without ruining everything, but it works as is.

Would it be possible to add this as an option in the GUI? I'll do it manually for now; but that doesn't help much for QR code users. A slider in the advanced for "Force DNS" with an input field for the DNS IP would be sufficient, I think. EDIT: For people who do set the DNS manually in the client configs and want the QR code updated as well: cd /etc/wireguard/peers qrencode -o peer-<hostname>-wg#-*.png < peer-<hostname>-wg#-*.conf (where # is the wg profile and * is the peer number) This will update the png manually.

Would it be possible to force a DNS server? Currently it looks like the client DNS is used no matter what, which means DNS leaks are a problem. It also means that hostname resolution for devices on the VPN doesn't work (for example http://<ServerName/ does not work, while http://<IP Address>/ does) Other than that seems pretty excellent so far. Edit: I tried adding DNS=<IP> in the wg0.conf and it didn't like it. Not sure what special sauce is needed.

FWIW; you can use something like sslh coupled with something like udptunnel to handle the UDP packets of wireguard over TCP on the SSL port (443) which is generally not blocked anywhere. This would be pretty manual to setup since the unraid implementation of wireguard doesn't "just have this" but there are dockers for BOTH of these things...

In my opinion, each docker should be listed inside the "network interfaces" box as selections. That way you can easily select which network to connect to. Perhaps add a "shared network" option to dockers so that the list doesn't get huge with too many dockers. Just need it to not switch from container name to container ID. To make this a bit more clear: In this screenshot we see that Nordvpn is configured for bridge mode networking. DDClient is configured for host mode networking (I start it in host mode for updating dns records with my real IP, currently. eventually I will change it to container:nordvpn) The third docker pproxy is configured manually going into advanced and putting --net=container:nordvpn. After saving the --net=container:nordvpn is converted to container:<uuid> This UUID is changed every time the container is modified. So if I change a setting, update the container, etc everything that is dependent on it's network now also must be manually updated again.

I too saw this behavior and have become frustrated by it. I would like to second this request. My implementation was for nearly identical purposes. Basically I setup a NordVPN container; added non-VPN friendly containers (including my sslh docker) to that docker's network and was off the the races. SSLH multiplexes my HTTPS and SSH traffic so they are both on Port 443. I'd rather not expose my public IP directly so I route all external traffic through the VPN connection leveraging this and nginx. Problem: Anytime the NordVPN container restarts or updates everything breaks and has to be manually corrected to --net=container.

Any chances of setting this up in Pterodactyl.io?

While this is fine for most use cases; and probably even "acceptable" for mine; it reaches limitations rapidly when hitting the disk with high network bandwidth. I have 10gbe uplink to my network. A single sata hard disk can hardly saturate gigabit; let alone 10gbe. If I'm transferring a large image on my network (500gb+ disk images) and a user wants to stream an episode of a tv show form the same disk as I am hitting - it might work. But if that TV show is 4k.... we've got a problem. The disk I/O demand is just too high. Yes, even spreading the data out, we can run into this problem - but it will be substantially more rare. I can then also further mitigate these issues by ensuring my large disk images are on a single share, and that those shares don't touch the disks with tv shows and movies. But we still hit disk I/O bottlenecks when multiple users are slamming the same drive. Enter cache, maybe? Sure - if you can reliably predict which data users are going to grab and cram all of that into a (relatively) small cache device; unlikely. In the above I highlight several (band-aid) fixes for the "problem" in the form of a lot of constant, manual server administration work. I paid for an unraid license because I don't want to fiddle with the server constantly. I have my Arch server, and I went down that road. I haven't had to do any manual administration on said arch server in over a year. This unraid box, I cannot say the same for - but that's growing pains. Once everything is set up the way I like and works properly, I won't need to fiddle. This is probably the single biggest downside to unraid. The throughput sucks. There are a lot of positives to a system like this, but the big detriment is that I/O performance is abysmal by comparison to a striped disk system. I keep teetering between whether I should continue to fill this server, or jump ship to a different platform while I can still afford to empty the drives and make the swap or not. I'm less inclined to just because I've paid for a license here.

Would it be possible to add support for a true scatter function? All of my disks are currently the same size. I'd like to keep files distributed among the disks to spread out the bandwidth use. Originally my files were distributed by unraid's High-Water option. I used unbalance to migrate data to 3 individual disks so I could switch to encrypted disks. Migrating data off those existing disks is where I realized the name "scatter" doesn't quite tell the story. Now I have 4 disks more or less permanently stuck at 100% usage making a much larger portion of my data reside on them. I can manually go through and select individual directories to spread the data out, but that's probably going to take several months.

Excellent idea; I may make a script to back up superblock information as well; as that could be used to recover a lot of data in the event of multiple disk failures. Should be fine without though.

I'm a solo, personal use user with more than 100TB of storage now. My original server from ~2012 was built into a U-NAS NSC-800. That server runs ArchLinux and is still live with some of the original disks still spinning (over 6 years power on time, it's getting scary so I'm cycling in new drives as I can afford to) That system had 8 2tb drives installed in Raid 5 with a hot spare with hardware raid, and it's been rock solid. The problem is I severely underestimated my "hobbyist" usage. I figured 12TB would last me for years to come, yet somehow a year or two later the system was nearly full and I was resorting to non-redundancy and no backups just to fit the bits on what I could afford. I was wrong. But, even saying that - technically almost all of my data could live happily on the cloud. And gigabit internet is "pretty quick" and "pretty affordable" now. Problem? I work with 500gb+ disk images and mounting over gigabit takes an eon. Moving the disk image back and forth constantly takes ages. 10gbe on a local server is the cure.

Wasn't meant to come off as an insult, I apologize if it did. Was just trying to be helpful, I'll go back in my hole now.

FYI, cryptsetup supports piping the keyfile via stdin: echo "securestring" | cryptsetup --key-file=- ...

This might not work since 1.16.7.1597 is a "forum only" preview.