Espressomatic

But there doesn't. Then either of two things: 1. You've misunderstood what they said 2. They're completely wrong If you can forward a link to any guide you've followed that says this, I'm curious to check. Anyway, your browser/OS already had a store of trusted CAs. If you're certs are issued by, for example, Let's Encrypt, you don't need an internet connection when you hit that cert at any point in the future after setting it up. Obviously you'll need an internet connection to initially procure and later renew the certificate every 60 days. Imagine my entire LAN being down just because my ISP had a hiccup. No, no thanks. 🤣 I use HTTPS and a FQDN for absolutely every single service I put through my browser hosted on my LAN.

Which is exactly what you will accomplish going the route I mentioned. TLS/HTTPS/RevProxy doesn't need internet. Vaultwarden doesn't need internet. LAN connections don't need Tailscale whatsoever. So I'm not sure what the issue is. It's the perfect solution for accessing Vaultwarden from anywhere outside your LAN. From inside your LAN, nothing besides Vaultwarden is needed (rev proxy if you want SSL and FQDN). Only when a node is specifically set to use the advertised route - which isn't automatic nor default. So, IMO moot for most installations. There's a good reason to use this, like when you have a node running on a virtual server off-premises, but generally no good reason to run it internally within the LAN. In addition, nothing in the setup of the firewall or router (as far as routing tasks go) should have any impact as the packets won't even hit the router, and go between only client and VW IPs. I'm making some assumptions here based on what else has been mentioned. One not mentioned is that there's a local private resolver/forwarder on the LAN so any query on a local FQDN never needs to go to an outside authoritative server. Example: PiHole, AdGuard Home (A record mappings), Unbound, DNSMasq, etc.

ping/dig duckdns.org - if that's working, then DNS may no longer be an issue, and it might be as simple as bad setup at duckDNS or challenge string. The error messages make enough sense to possibly point in the wrong direction - example what invalid domain? Duckdns itself or the domain you're running the challenge against?

Using a reverse proxy (always HTTPS), no need for special serve settings for Tailscale and no issues whether any PC/device (on the LAN) is, or is not, connected to the Tailnet when using Bitwarden client/plugin. When away from the LAN, must use the tailnet, as expected. Easy setup, easy to manage, always works. Reverse proxy is highly recommended to allow reaching Vaultwarden and other services by HTTPS using FQDN.

That won't work, as NPM uses a database to store everything it shows in the UI. You'll have to configure everything again from scratch for the least number of headaches. If the NPM docker is installed as instructed and your Unraid system's DNS works, then it will also work from within the NPM docker, so I suggest starting over, and deleting your NPM appdata folder to make sure nothing is reused.

I understand your comments weren't targeted at plugin developers. But your opinions about Unraid in this regard are misplaced and simply incorrect. You don't need a plugin to read sensors. lmsensors is built in. Sensor-detect is built-in. Drivers for ALL sensors are not built in. So here's an idea. How about posting a suggestion to have the Fan Control and Sensors plugin(s) installed and available by default in Unraid? Plenty of other built-in functionality originally required manually installing a plugin. Some similar suggestions already exist, I've ever posted a few myself, asking for very specific plugins to be standard/default. It seems like most people prefer an a-la-cart solution like we have now. Now it sounds like you're taking the piss. If those solutions offered what Unraid does, then I argue that you wouldn't be here. Now, maybe they include some additional drivers and defaults, but what they lack compared to Unraid can fill a canyon. Unraid is getting more turn-key, but until it's "all the way there" it takes very little effort to install the necessary plugin.

It is possible. But if you don't intend to run an outside server, you should not self-host the Netbird management component. Use Netbird's own server for this, they have a generous client limit allowed for free. Jim makes good videos, but IMO, this one is a little convoluted. Adding Authentik is an unnecessary step because it adds no extra security if you don't open ports - no one can access those services without Netbird and your keys. By opening ports on your router you are making a big hole around Netbird's VPN and and open yourself up to unnecessary attack vectors. And I would never trust Authentik to the hammering your LAN will receive 24/7 with open ports and services. Since we're here in the Unraid forum, I strongly suggest a much better approach is to use Tailscale which is built into Unraid with Plugin and direct Docker support. It is easier to set up than Netbird, IMO, and doesn't additionally rely on a third party component like Coturn (which Nebird itself is going to try to replace eventually). Just my 2 cents. Tailscale is pretty easy to set up and works well with NPM.

Here's a bit of a counter point: Chrome doesn't appear in the privacy settings on my system(s) and works fine to access Unraid. I haven't a clue as to how apps appear in that list frankly. Floorp (my primary browser) is there, but I know I didn't have to enable it manually.

I didn't say that, nor imply it. What I'm saying is that it's not a valid comparison, as Ubuntu is a general-purpose desktop distribution (not a NAS) packed with a lot of drivers and other components ready to go, whereas Unraid is a minimal distribution deployed on a small USB key using Plugins to support very specific use cases.

Yes, 100%. If your self-hosted instance were able to be accessed without Tailscale, then there would be no point in having Tailscale deployed. It's a peer to peer VPN. I've installed Tailscale on the devices of all family members in the house. Those are the only people who can access resources on my LAN from outside.

That is incorrect. You're confusing server with router. In your example it's talking about self-hosting the management component, which is done on a server outside your network - it doesn't make any sense to do it on a server inside. That server needs those ports open. Your LAN definitely does not need to be open or have any permissive firewall rules. This zero-config property for the LAN is one of the primary selling features behind Netbird and similar solutions.

Have you checked the installation size of Ubuntu compared to Unraid lately?

How and from where are you trying to access that IP? The inability to reach a Tailscale IP means you're not running Tailscale on the device you're connecting from. You can't access tailnet IPs if you're not connected to the tailnet.

You have a bad DNS configuration. https://community.letsencrypt.org/t/failed-to-establish-a-new-connection-errno-3-temporary-failure-in-name-resolution/170617

You don't open ports on the router/firewall at all when using wireguard-based VPN like Netbird - everything incoming on your firewall should be closed. You can run 2, 3, 100 different IPs on your LAN, it doesn't matter. The Netbird clients running on each of those machines communicating with the Netbird coordinator establishes a route to each machine using Netbird-specific IP range - that's how you can connect from the outside to any specific machine - your WAN IP doesn't matter and neither does its ports. The local reverse proxy (NPM) works to add certificates and proxy services using domain names that don't rely on your Netbird mesh. IMO, you should consult a few Netbird and Tailscale Youtube videos to brush up on the basics of what they offer and how they work. I think that will clear up a lot of the confusion.

.local is a special case advertised by mDNS. If you want to test regular DNS, you can try resolving outside hosts or internal hosts that don't use mDNS. If everything's using mDNS then no worries for all internal traffic.

Did you by any chance see the custom network at the bottom of your Docker settings and configure the subnet and gateway there? I played around a bit just to see if I was able to create and assign the network - which I was. But I'd have to make additional changes to allow connecting to a different subnet from the first to then properly test the docker's DNS - which I haven't done.

Is it possible there's a network issue on that Mac? Safari vs. Chrome vs. Firefox have nothing to do with each other and HTML/JS issues with one won't affect another just because they're running on the same system. The exception is the underlying network possibly preventing finding the resources and/or loading them slowly - proxy, firewall, DNS, routing, bandwidth.

This is how I normally (quickly) verify which are active: Active scripts show those icons on the right. Disabled ones have no icons.

Yes, thanks. Give me a couple of days to go over everything with a closer look, as I want to redeploy from scratch using my instructions to make sure they're clear and work as expected. I wrote that after setting up myself and need to make sure I didn't accidentally forget something.

[Final reserved post] - First post is being edited right now

[Reserved for additional content]

Here's a bit of info about an NPM installation that's working solidly for me. You should install Tailscale using the Tailscale plugin for Unraid on every Unraid machine, then on any machines and mobile devices you plan to also use within the tailnet. You can install NPM inside a Linux Container (instead of docker) along with Tailscale. Running NPM on Debian LXC - Instructions: Installing NPM in an LXC: https://medium.com/@rar1871/nginx-installing-proxy-manager-in-lxc-v2-debian-d4d4c98109b1 Script for above instructions: https://github.com/ej52/proxmox-scripts/tree/main/apps/nginx-proxy-manager Setting up Tailscale on Debian (in the LXC): https://tailscale.com/kb/1174/install-debian-bookworm Install LXC Plugin on Unraid from Community Apps (I like to use Default Network br0) https://forums.unraid.net/topic/123935-plugin-lxc-plugin/ Go to LXC page/tab next to Docker page/tab Add LXC Container Enter a name for your container (no spaces) Enter an optional description Distribution: Debian Release : Bookworm MAC Address: (automatically generated - or enter your own) Start after creation: ON Click icon for container and select Terminal Install Updates & a couple of packages needed for the installations to follow apt-get update apt-get upgrade apt-get install apt-utils apt-get install wget apt-get install curl Nginx Proxy Manager install using script in LXC sh -c "$(wget --no-cache -qO- https://raw.githubusercontent.com/ej52/proxmox/main/install.sh)" -s --app nginx-proxy-manager Click container icon and Show Config Copy the location of the config file to clipboard (/mnt/path_to_config_file…) Stop container Open Unraid terminal and edit the config file (nano /mnt/path_to_config_file…) Add the following to the end of the LXC Config (TUN access so Tailscale can create its network) #Allow TUN access lxc.cgroup2.devices.allow = c 10:200 rwm lxc.mount.entry = /dev/net/tun dev/net/tun none bind,create=file #Resource limitation lxc.cgroup2.cpuset.cpus = 1 # This is a CPU core or list of cores to use for the LXC - omit line to allow all cores lxc.cgroup2.memory.low = 256M lxc.cgroup2.memory.high = 768M lxc.cgroup2.memory.max = 1024M Save the config file Close terminal Start LXC container Open Terminal into LXC container Create pre-shared key from your Tailscale Admin page https://login.tailscale.com/admin/machines/new-linux Click the Generate button at the bottom Copy (only) the text after "--auth-key=" - it should start with "tskey-auth-..." Install Tailscale inside LXC First the package sources curl -fsSL https://pkgs.tailscale.com/stable/debian/bookworm.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null curl -fsSL https://pkgs.tailscale.com/stable/debian/bookworm.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list Next the install sudo apt-get update sudo apt-get install tailscale Finally running/activating (paste the tailscale up command with the key you copied earlier) sudo tailscale up —auth-key AUTHORIZATION_KEY_GENERATED_ON_TAILSCALE_ADMIN_SITE Access your NPM installation - make sure you enter HTTP and NOT HTTPS or the page won't load http://IP_ADDRESS_OF_LXC_CONTAINER:81 Name: [email protected] Password: changeme You'll need to create DNS resolver overrides for Unbound if running that, or DNS entries in something like PiHole or AdGuard Home to send specific subdomains to your NPM IP. NPM cert and proxy for every service/FQDN gets filled in the same way as if you were using it from Docker. Don't forget to make a proxy entry for NPM itself.

No, this doesn't need to be done to generate certificates and using DNS challenge. And shouldn't be done at all - use Tailscale AFTER setting up NPM locally, including certificates. Looks like your NPM container is messed up. Use NPM-Plus. You don't need this. Even your A-record doesn't need to point to your IP if you set up Tailscale, which is the secure way of accessing your local services from outside your LAN. You're trying to do too many unrelated steps at the same time and because of that it's difficult to follow and figure out where things are going wrong. I'm tempted to suggest you blow away the entire NPM config and just start over from a Youtube guide. This is a pretty simple process and there's little to no reason it shouldn't work immediately after a few steps which only take minutes.

It sounds like you have something configured with Cloudflare settings (Credential file contents text box?) and are using a different DNS challenge setting (like DuckDNS). I strongly recommend to use Cloudflare or Registrar like Porkbun with a real FQDN rather than using DuckDNS. But Duck should still work if you make sure that the credentials text box is filled out correctly. I don't understand what you're trying here. If you have NPM working correctly, any visit to your FQDN should automatically be reritten as HTTPS and use the cert. It doesn't matter if you type http or https or nothing when hitting the site from your browser. NPM is listening on both port 80 (http) and 443 (https). Do *all* your testing from inside your LAN only. Don't bother trying any connections from the WAN side until you know everything is working 100% I also strongly recommend closing all incoming ports on your firewall and using Tailscale instead - but just like above, only after making sure everything is 100% inside the LAN.