ljm42

I don't know what would cause vfio-pci to skip devices, but as part of migrating this functionality to Unraid 6.9, everything vfio-pci does during bootup is now logged. More info here: https://forums.unraid.net/topic/93781-guide-bind-devices-to-vfio-pci-for-easy-passthrough-to-vms/ Check it out when 6.9 is released, or try a beta if you are feeling adventurous: https://forums.unraid.net/bug-reports/prereleases/

This is resolved in the latest version of the Dynamix WireGuard plugin

On the Plugins page, click the information icon to see the changelog

The issue is DNS. When you use a browser to visit https://yourhash.unraid.net, your computer does a DNS lookup to translate the hostname into an IP address, something like 192.168.1.2 But if your Internet is down and the DNS lookup fails, the browser won't be able to get the IP address for that hostname. I don't use pihole myself, but I imagine it has a way that you can hard-code an IP address for a given hostname so that it will respond correctly even if your Internet is down. Google should be able to help with that. Another option would be to modify the hosts file on your computer (not Unraid, the computer with the browser on it) so it will resolve yourhash.unraid.net to the correct local IP address. Google can help with that too. Just keep in mind if your Unraid's IP address ever changes you'll need to go back and update whatever you hard-coded.

The reason for "adding a tick" to a device is to ensure Unraid doesn't install any drivers for it, thus leaving the device available to be passed through to a VM. I'd guess that Unraid doesn't load audio drivers right now so it isn't strictly necessary to bind the audio device to vfio-pci. But I'd probably add the tick anyhow, in case something changes in the future.

We need more details. I'm not really clear how you are getting an invalid cert error, unless you are going to https://<ip address> What happens if you go to: http://<ip address> NOTE: it must be http, not https. There is no certificate for the ip address.

The dashboard is simply formatting the output of the "wg show" command provided by WireGuard. wg does not provide a counter of "how long" a device was connected, probably because it is designed to let connections seamlessly drop and reconnect. It does show the amount of data that was transferred though. I guess WireGuard feels the length of time somebody was connected is less important than the amount of data they transferred.

I'm looking into this. To clarify, what browser on what device are you using when you do this? From my testing, it appears to be a browser issue. When I use press the Apply button using Chrome on Android, the tunnel stops but does not start back up. If I use Chrome on Windows it works fine. In either case, it does not matter whether I am connected via WireGuard or direct via wifi. Can you confirm that you see the same?

Realtek came up in another thread today too: In general, you're better off avoiding Realtek in Unraid. The may work OK in Windows, but their Linux drivers are hit and miss. They will work in one version and then have problems after an upgrade.

"Active" simply means the tunnel is enabled on the Unraid side, has nothing to do with whether someone is currently connected to it. The "handshake" column shows that "Peer 1" last connected to tunnel WG0 7 minutes and 23 seconds ago. If you no longer want the tunnel to be available for connections, go to Settings -> VPN Manager and change the "Active" slider for tunnel WG0 to "Inactive". If you want to "forget" the fact that "Peer 1" connected 7 minutes and 23 seconds ago but still keep the tunnel up, change the slider from Active to Inactivate and then back to Active. That will clear the connection list.

This is discussed here:

"Unassigned Devices" is both a generic term that means "disk not assigned to the Unraid array" and the name of a plugin which adds capabilities to disks not assigned to the array.

Here is a guide that describes the new System Devices page and how you can use it to bind devices to vfio-pci:

I just upgraded to 6.9, how can I take advantage of this? - or - Help! Fix Common Problems says "Legacy PCI Stubbing found", what do I need to do? At some point in the past you added a 'vfio-pci.ids' or 'xen-pciback.hide' directory to your syslinux file, similar to this: vfio-pci.ids=8086:1533 xen-pciback.hide=0000:03:00.0 This is the old way of stubbing a device so that Unraid will not install a driver for it. In 6.9 we do that using the webgui. First go to Main -> Boot Device -> Flash and choose "Flash backup". This will give you a zip file of your settings "just in case" Then go to the Syslinux tab on that page and remove the "vfio-pci.ids" or "xen-pciback.hide" attribute from the "Unraid OS" section. It probably looks something like this: kernel /bzimage append initrd=/bzroot vfio-pci.ids=8086:1533 and you want it to look like this: kernel /bzimage append initrd=/bzroot Hit Apply, but don't reboot yet! Then go to Tools -> System Devices and put a checkmark next to the device you want to stub and and click "Bind selected to VFIO at boot" Now reboot. When it comes back up, the System Devices page will be in control of what devices are stubbed to VFIO-PCI. You can press "View VFIO-PCI Log" to see exactly what it did for that device while booting.

TL;DR - skip to the second post if you just want to know how to convert from legacy PCI stubbing via Syslinux to the new point and click method in Unraid 6.9 --- At times you will want to "hide" devices from Unraid so that they can be passed through to a VM. Unraid Prior to 6.7 In the past (pre Unraid 6.7) we would stub the device by adding a Vendor:Device code to the vfio-pci.ids parameter in Syslinux, something like this: append vfio-pci.ids=8086:1533 This worked, but had several downsides: If you have multiple devices with the same Vendor:Device code, all of them would be stubbed (hidden) from Unraid It is a fairly technical process to find the right Vendor:Device code and modify the syslinux file. Make a mistake and your system won't boot! As an alternative, you could add the <Domain:Bus:Device.Function> string to the xen-pciback.hide parameter in Syslinux: append xen-pciback.hide=0000:03:00.0 This had downsides too: Still a technical / risky process If you add/remove hardware after modifying syslinux, the pci address could change and the wrong device could end up being stubbed. This would cause problems if a critical disk controller or NIC were suddenly hidden from Unraid This broke in Unraid 6.7. More details Unraid 6.7 Starting with Unraid 6.7 we could bind devices to the vfio-pci driver based on the <Domain:Bus:Device.Function> string (aka pci address). You needed to manually modify the config/vfio-pci.cfg file and specify the <Domain:Bus:Device.Function> string, like this: BIND=03:00.0 This worked, but still had several downsides: It was a fairly technical process to find the right string to place in the file. But at least if anything went wrong you could simply delete the config file off the flash drive and reboot. We still had the problem where if you add/remove hardware after modifying the file, the pci addresses could change and the wrong device could end up being bound to vfio-pci Unraid 6.9 For Unraid 6.9, Skittals has incorporated the excellent "VFIO-PCI Config" plugin directly into the Unraid webgui. So now from the Tools -> System Devices page you can easily see all of your hardware and which IOMMU groups they are in. Rather than editing the config file by hand, simply add a checkbox next to the devices that you want to bind to vfio-pci (aka hide from Unraid). If a device is being used by Unraid (such as a USB controller, disk controller, etc) then the web interface will prevent you from selecting it. Additionally, we have a new version of the underlying vfio-pci script which can prevent the wrong devices from being bound when hardware is added or removed. When you click to bind a device on the System Devices page, it will write both the <Domain:Bus:Device.Function> and the <Vendor:Device> code to the config file, like this: BIND=0000:03:00.0|8086:1533 In this example, the updated script will bind the device at pci address 0000:03:00.0, but only if the <Vendor:Device> code is 8086:1533. If a different <Vendor:Device> code is found at that address, it will not bind. This means we will never inadvertently bind a device that is important to Unraid! (However, since the desired device is not available to be bound, the VM expecting that device may not function correctly.) Devices bound in this way can be passed through to your VMs by going to the VM tab, editing the template, and then selecting the appropriate device from one of the hardware dropdowns. Can't find it? Check under "Other PCI Devices". If the System Devices page shows that multiple devices are in the same IOMMU group, it will automatically bind all the devices in that group to vfio-pci. You should then pass all devices in that IOMMU group to the same VM. Note: If you make hardware changes after setting this up, it would be a good idea to disable autostart on your VMs first. Then shutdown, add/remove hardware as needed, and boot back into Unraid. Visit the Tools -> System Devices page and ensure the correct devices are still being bound to vfio-pci. Adjust as needed and reboot, then start your VMs. Troubleshooting Tips If you had the VFIO-PCI Config plugin installed, you should remove it as that functionality is now built-in to Unraid 6.9 General tip for Unraid - if you intend to try something that feels risky, go to Settings -> Disk Settings and disable Array Auto Start before you shutdown. This will minimize the chance of data loss on boot. If all goes well you can start the array up after booting. If you bind your only video card then Unraid probably won't boot. See the next point. The System Devices page writes the device details to config/vfio-pci.cfg file on the flash drive. If you ever want to "start fresh" simply delete this file and reboot. If there was a vfio-pci.cfg file to process during boot, System Devices will include a "View VFIO-PCI Log" button that details each of the devices that were (un)successfully bound during boot, along with any available error messages. Be sure to upload your diagnostics ( Tools -> Diagnostics ) when requesting help as both the config file and the log are included in it

the static route is definitely required

Change the slider from Basic to Advanced, then on the "Local server users NAT" line there is a comment telling you what static route needs to be setup in your router. There are more details in the "Complex Networks" portion of the first post of this thread. This can help whether you have "Use NAT" set to yes or no, particularly if the "devices" are you are trying to reach are hosted on Unraid.

Sorry, I can't think of anything. The static route you added on the router should have allowed the tunnel to work with NAT disabled.

Are you trying to access the LAN devices by name or IP? You haven't specified a Peer DNS server, so you will need to access the devices by IP address. See the "About DNS" section of the first post.

Glad you got it working, that is not something I would have thought of "Remote tunneled access" pushes all of your client's traffic through the tunnel, including DNS requests. I'd guess you are having DNS resolution issues, see the "About DNS" section of the first post. "Remote access to LAN" uses split tunneling, where only traffic destined for Unraid and its LAN go through the tunnel. All other traffic uses the client's default network stack.

Troubleshooting WireGuard is tough because it either works or it doesn't, and when it fails it fails quietly so there aren't any hints as to what the problem is. I don't see anything obviously wrong, best I can do is recommend that you go through the troubleshooting steps in the second post.

It sounds like the structure of your certificate isn't setup quite right for Unraid. Unraid uses the "CN" (common name) portion of the certificate. If the CN contains a *, the * is replaced with the hostname, otherwise it is assumed the CN is correct as-is. If you SSH to your server and run this command, it will show you the CN for your certificate: openssl x509 -noout -subject -nameopt multiline -in /path/to/cert/bundle.pem |sed -n 's/ *commonName *= //p' If the result of that command is something like this: *.mydomain.com then Unraid will change the * to your hostname, and redirect to that: tower.mydomain.com If the result of that command does not include a *, it is used as-is.

It doesn't look like you've started the tunnel, try changing the "inactive" slider to "active" If you haven't had a chance to read it, the first post of this thread contains step-by-step instructions

OK typically when people say "hang" they mean their system doesn't respond when they to access it. That doesn't sound like the issue here. If you refresh the page what happens? Does the uptime continue to increase? SSH to the server and type "wg show". What does it say the uptime is? p.s. it is late here, I will try to respond again in the morning

Hmm... I don't see anything about Unraid hanging in your other post?