Jump to content

ljm42

Community Developer
  • Content Count

    1613
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by ljm42

  1. Plugin Name: UPnP Monitor. Install using Community Applications. Minimum Unraid version: 6.8.0 Source code: https://github.com/ljm42/unraid-upnp This plugin gives visibility into the UPnP activity on your network. It uses the upnpc client that ships with Unraid to contact the UPnP server running on your router to get a list of all the UPnP port forwards that have been setup on your network. You can review the list and take action (limited) if there are any that you do not expect to see. The plugin offers a debug mode if you would like to see the exact commands that it runs to get the data. I may remove this at some point. There is also a refresh button to get the latest data from the router without reloading the whole page. Notes / Caveats: The UPnP client is disabled by default in Unraid, you can enable it on the Settings -> Management Access page. Unless you do that, this plugin will not be useful. Note: In Unraid 6.8.0 you also need to have the WireGuard plugin installed in order to see the option to enable UPnP. Starting with 6.8.1 this is no longer necessary. Similarly, if you have disabled UPnP on your router then this plugin will not be useful. I only run IPV4, so it is possible that the plugin will not parse IPV6 addresses properly. If you notice any parsing problems, please PM me the output of the debug screen and I'll take a look. UPnP and Security Many people feel that UPnP is a security risk because it requires no authentication - any application on your network is able to forward a port through the router. On the flip side, it is super convenient If you are running UPnP on your network, you can take the following steps to take to reduce your risk (no warranty or guarantee is implied): Update your router's firmware. Older versions of UPnP had security issues so it is important to stay fairly current. In general, if your router isn't getting regular updates you should probably replace it. If your router has an option for "secure mode UPnP", enable it. This makes it so that a computer on your network can only forward a port to itself. Without this, any computer on the network can forward a port to any other computer, which is definitely a security concern. In some routers this may be enabled by default with no option to disable it. High-end routers like pfSense and OPNsense allow you to restrict which IP addresses are allowed to make UPnP calls to setup port forwards. You can use this to limit your risk by only allowing trusted computers to do this. Review the list of active UPnP port forwards so you are aware of how it is being used. Your router may or may not provide this functionality. That is the purpose of this plugin. Delete any UPnP port forwards you no longer want. This plugin assumes your router is running in "secure mode", so it will only let you delete port forwards that point at Unraid's main IP address. To delete port forwards that point to other IP addresses you would need to look for that option on your router. You may be able to delete them en masse by disabling/enabling UPnP on the router, or rebooting it. Of course, this will not prevent them from being created again in the future. For that you need a router that allows the restrictions mentioned in item 3 above, or simply disable UPnP on the router.
  2. You can run the underlying wg commands if you want, but you can fully monitor everything right from the Unraid dashboard. Pretty cool.
  3. 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.
  4. 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.
  5. 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.
  6. 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)
  7. 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/
  8. 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.
  9. Try getting a free config from TunSafe and comparing them to see what is different? Also note the comment about DNS in the OP
  10. 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.
  11. 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
  12. That is a good data point, thanks! Oh and for the record, I am using UPnP. With bridging (not bonding) on br0.
  13. 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.
  14. 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
  15. Not sure what happened, but hopefully you saw this in the Troubleshooting section of the guide:
  16. 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.
  17. 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.
  18. Depends on what you are trying to do. See the description and diagram in the first post of this thread.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. diagnostics showing the problem are critical to helping understand what happened and how to prevent it for other people
  24. You are getting lots of these errors: Unraid-Server kernel: tun: unexpected GSO type: 0x0, gso_size 1366, hdr_len 1432 Also see: