ljm42

Forwarding a port to WireGuard means you have to trust WireGuard, the underlying OS doesn't really matter. You probably shouldn't forward other ports to Unraid, but once you have VPN there is less of a need for that anyway. WireGuard is in the base OS so that it will start when the server boots, whether or not the array is started. You can start and stop dockers and VMs, start and stop the array, and adjust must of Unraid's config (other than the network), all while connected over VPN. If you are happy with your current solution that is great! Nobody is saying you have to switch. If you do try it out I think you you will be amazed at how quickly your remote devices make a connection as compared to other solutions - it is almost instantaneous. And the throughput will likely be better as well.

Just one thing? Probably the core NAS functionality of adding mismatched drives, one at at a time. But I also really like the application ecosystem that allows you to run plugins, dockers and VMs too. Oh and WireGuard. For 2020 I'd really like to see a built-in firewall, such as UFW. And a mobile-friendly webgui.

That is way beyond this guide and will require you to read up on Wireguard. The plugin takes care of all the details for you *if* it is managing the tunnel. If you are connecting to another tunnel that is not managed by Unraid, you will need to deal with setting up the private/public keys, assigning the IP address, determining the endpoint urls, etc. All of this is Wireguard specific, nothing to do with the fact that the client is Unraid. Once you have created a config file for the Unraid client that will connect to your other system, choose the "Import config" option in the plugin. I honestly haven't done that in a while so I don't recall the exact steps after that. But it should get you close. There is really only one caveat that I can think of - Unraid will ignore any dns server setting that is in the config file, probably best to just leave that out. Everything else is standard wireguard. Note that everything mentioned in the second post still applies - troubleshooting is very difficult because wireguard fails silently. There are no helpful logs to look at. It works or it doesn't.

yes

It depends on which "Peer type of access" you choose. "Remote tunneled access" pushes everything through the VPN tunnel, the others do split tunneling (where only the traffic destined for Unraid's network use the VPN tunnel)

Try the timeout command: timeout 10 wget --user=user--password='pw' ftp://adr:port/file -O /root/keyfile That will start wget and then kill it if it is still running after 10 seconds. More details here: https://www.howtoforge.com/linux-timeout-command/

Wireguard is very difficult to troubleshoot because it fails silently - there are no error messages or logs. But based on what you've said, it sounds like your port forward isn't working correctly. By default the guide gets you setup with one of the "split tunneling" options, where only traffic destined for your server (or LAN) goes through the tunnel. If you want all your traffic to go through the tunnel you need to choose the "Remote tunneled access" option instead. I'd suggest getting "Remote access to LAN" working first though.

Try getting a free config from TunSafe and comparing them to see what is different? Also note the comment about DNS in the OP

Am I wrong or does their implementation require you to use their NordLynx client? If so that won't work with the standard WireGuard client that we use. If you can provide a link that shows how to download a standard WireGuard config file, I'll link to that.

The problem seems to be unique to your installation of Firefox. Try a new Private Window in Firefox. If that doesn't work, create a new blank profile: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles

That is a good data point, thanks! Oh and for the record, I am using UPnP. With bridging (not bonding) on br0.

It isn't just you. I complicated my network a bit to try and reproduce this, and I'm seeing it too. I amended the guide to acknowledge this. Still looking for a solution. I'm glad everything is working for you @nuhll, but your network is rather unique I'm not sure how we can leverage that into a solution that will work for everybody.

I have amended the guide, there is now a section for "Complex Networks" that talks about setting "Use NAT" to "No" and adding a static route in your router. This is needed if you have Dockers with custom IPs or certain VM setups. These changes should allow everything on the network to work normally. However, as several people have seen, your WireGuard clients may not be able to access those Dockers or VMs. This still needs to be figured out. If you find a solution, please comment

Not sure what happened, but hopefully you saw this in the Troubleshooting section of the guide:

Activity with no handshake is odd, I don't think I have seen that before. Not sure what you mean by "static route"? Are you trying to get around issues with VMs or dockers? I'd remove that until you get the basics down first. i'd recommend you start with the scenario in the guide, "remote access to LAN". If you can get that working that will prove all the basics are good. If you have issues with that, go through the troubleshooting section with a fine tooth comb. Once you have the basics working you can move on to the other options.

No, as mentioned in the first post, you really need to trust the people that you give this VPN access to. Regardless of which access type you choose, assume the user could get full access to your LAN. If you really want to do it, you could potentially put WireGuard on a raspberry pi on its own VLAN. But that is well beyond the scope of what we are trying to do with this plugin.

Depends on what you are trying to do. See the description and diagram in the first post of this thread.

OK, so 192.168.20.1 is the direct IP of your router, without using VPN. And 10.8.0.1 is some sort of VPN running on your router? I see no evidence of Unraid being used as a gateway or anything super strange like that. I would look closer at how your router determines whether to send traffic through 10.8.0.1 or 192.168.20.1. Is it based on IP address or MAC address maybe? If so, you'll have to figure out why the router thinks the IP or MAC has changed.

On the VM, try running "tracert www.google.com" in various configurations and see what changes. That will show you the path that the system is taking to get out to Google.

I don't use dockers with custom IPs. The best information is in this thread, I'd suggest following the discussion over there rather than starting a new one Not that I can see. As mentioned in the OP, I'd suggest using a hosts file if you must have name resolution. You could possibly use the LAN's DNS server, but that doesn't make sense for split tunneling.

When I was testing a few days ago, it seemed like I needed to add a DNS server for "Remote tunneled access" to work. Maybe i was just tired or something because my Android is currently connected using an unedited config file and it is working fine. All traffic is going through WireGuard without having to make any customizations. During this time I did upgrade the host from rc1 to rc3, which includes a newer version of WireGuard. So it is possible that made a difference. Edit - I did find a use case where you NEED to enter a DNS server for the tunnel. When my Windows laptop is connected to my home network via wifi, if I type "nslookup" it shows the DNS server is my local router. If I then make a "Remote tunneled access" connection to an Unraid system on another network, the router on my network is no longer available for DNS. So I have to include a DNS server in the WireGuard config. Specifying either the remote router or a global server like 8.8.8.8 work equally well.

diagnostics showing the problem are critical to helping understand what happened and how to prevent it for other people

You are getting lots of these errors: Unraid-Server kernel: tun: unexpected GSO type: 0x0, gso_size 1366, hdr_len 1432 Also see:

Unraid uses PHP's built-in session handler. So once you have been inactive for an hour (i.e. you close the tab that was logged in to Unraid), anytime a PHP script runs there is a 1% chance that it will run PHP's session cleanup code and delete your session. If the session hasn't been deleted, then the next time you access a page in the Unraid webgui the session will be extended. Sessions are based on temporary cookies. So you can also kill your session by completely closing your browser or by deleting your cookies. Note that if you just close a tab that will not delete the temporary cookies. If you leave a tab open and pointed at the Unraid webgui, there are scripts that poll the server regularly that will prevent the session from timing out. So to recap: If you login to the Unraid webgui and leave the tab open, it is unlikely that the session will ever expire and log you out. If you close the tab, you could be logged out after one hour but it may not happen If you close the browser entirely or otherwise clear your cookies, you will be logged out

Thanks for this call out, I've added it to Troubleshooting section. I think you might be right about needing to specify a DNS server when in "Remote tunneled access" mode. I'll do some more testing