Melmi

Yes, but only if your firewall is set to reject instead of drop. The documentation you linked mentions this; that’s why open ports are listed as open|filtered because any port that’s “open” might actually be being filtered (dropped).

On a modern firewall, an nmap scan will show every port as open|filtered, regardless of whether it’s open or not.

Edit: Here’s the relevant bit from the documentation:

The most curious element of this table may be the open|filtered state. It is a symptom of the biggest challenges with UDP scanning: open ports rarely respond to empty probes. Those ports for which Nmap has a protocol-specific payload are more likely to get a response and be marked open, but for the rest, the target TCP/IP stack simply passes the empty packet up to a listening application, which usually discards it immediately as invalid. If ports in all other states would respond, then open ports could all be deduced by elimination. Unfortunately, firewalls and filtering devices are also known to drop packets without responding. So when Nmap receives no response after several attempts, it cannot determine whether the port is open or filtered. When Nmap was released, filtering devices were rare enough that Nmap could (and did) simply assume that the port was open. The Internet is better guarded now, so Nmap changed in 2004 (version 3.70) to report non-responsive UDP ports as open|filtered instead.

WG uses UDP, so as long as your firewall is configured correctly it should be impossible to scan the open port. Any packet hitting the open port that isn’t valid or doesn’t have a valid key is just dropped, same as any ports that are closed.

Most modern firewalls default to dropping packets, so you won’t be showing up in scans even with an open WG port.

It definitely encrypts the traffic, the problem is that it encrypts the traffic in a recognizable way that DPI can recognize. It’s easy for someone snooping on your traffic to tell that you’re using Wireguard, but because it’s encrypted they can’t tell the content of the message.

Goes to show I don’t know much about SSO I suppose. Time to do some more research

I had issues connecting to Nextcloud from mobile clients when using Authelia, they didn’t like it, but if there’s a workaround for that that’s great

Most things should be behind Authelia. It’s hard to know how to help without knowing what exactly you’re doing with it but generally speaking Authelia means you can have SSO+2FA for every app, even apps that don’t provide it by default.

It also means that if you have users, you don’t need them to store a bunch of passwords.

One big thing to keep in mind is that anything with its own login system may be more involved to get working behind Authelia, like Nextcloud.

Why would a random browser extension take it upon itself to snoop on your traffic to ensure that the websites you’re using can’t be used for illegal things, and then intentionally break it if it detects something it thinks it’s illegitimate? That’s a huge breach of privacy. It’s just malware at that point. It’s not like a court of law would hold your browser extensions responsible for your piracy. That’s like blaming a cup holder because the car was used in a robbery.

No, I think this is just a bug. Especially since people have reported that the extension breaks other websites too.

I don’t get why they call hosting a mail server being your own ISP. It’s a very very loose definition of the term “ISP” there. ISPs may provide mail services on the side, but that’s not what makes them an ISP imo—its providing internet access that makes them an ISP.

On looking it up, apparently some people consider email providers ISPs in their own right though? Seems like confusing terminology.

This project uses mDNS, which is specific to the .local TLD. The whole reason that people are against the use of .local is because it would break mDNS. So you can set a custom TLD, but it doesn’t matter because this is actually the correct context for .local to be used, and changing the TLD will actually break things for a lot of clients.

10.50.50.0 is not a valid IP address in most configurations. Have you tried 10.50.50.1?

Docker containers are more like LXCs—in fact, early versions of Docker used LXC under the hood, but the project diverged over time and support for LXC was eventually dropped as they switched to their own container runtime.

If you’re already using Wireguard, it’s super easy to add a VPS to your Wireguard network and route all traffic through it. Then you can port forward pretty easily using some iptables rules from the VPS public IP to an IP on the Wireguard network.

That said, doing it that way will involve routing all of your traffic through the VPS, which means you’ll need a good low latency connection to your VPS. (You can set up split tunneling, but it’s a bit of a hassle to do that and port forwarding.) An alternative would be to set up a reverse proxy on the VPS, and reverse proxy your VPN IP.

Any non-proxiable services probably shouldn’t be exposed directly to the internet anyway, and you can simply expose them via VPN.

As long as you have access to a a command line, you can install it manually. It’s worth noting though that I did a cursory internet search, and it seems like the developers are strongly against installing AGH on IPFire directly—plus it would take some hackiness to even get it installed on IPFire directly. That said, IPFire supports VMs, so you could run AGH in a VM on IPFire.

AGH can also be installed alongside OPNsense or pfSense as well, either by installing manually or in the case of OPNsense there’s a plugin in the community repo

What is TrueNAS adding to this arrangement? Generally when people run two different servers at home, they keep the VM drives on the hypervisor and just use the NAS for storing bigger things like media files. Hosting VM drives over iSCSI works in an enterprise environment, but if you can’t guarantee uptime for your storage solution then all you’re doing is adding failure modes.

It seems to me that your best bet is to go down to one server, which means cutting out either TrueNAS or Proxmox. Both can handle both storage (ZFS included!) and VMs, so ultimately it’s a matter of which you like better.

Alternatively, if you’re hosting other stuff on your NAS, you could consider keeping both servers but just getting a few SSDs to stick in your Proxmox mini PC to serve VMs. That may or may not be viable for your situation, but it’s worth considering.

A lot of people like having a NAS VM like OpenMediaVault or TrueNAS that handles their drives via passthrough.

It sounds like you would prefer a lighter weight option—the way my storage is set up is ZFS pools handled by Proxmox itself, then bind mounted from the host into containers that handle the actual file sharing portion. I have separate, self-configured containers for Samba and NFS, but there are turnkey options in the proxmox template menu if you’d prefer.

Ideally, you’d spin up a dedicated container for every service. Combining services somewhat undercuts the advantages of having them in containers to begin with.

I’m not sure of the cause, but this is an issue with the Web Player on the Jellyfin app. You can fix it by going to Settings -> Client Settings -> Video Player Type and selecting Integrated Player or External Player.

I find it disappointing that everyone’s first suggestion in the selfhosted community is Cloudflare. It seems to run counter to the spirit of selfhosting to hand off the last part to the giant corporation that controls 90% of the Internet.

Most of what Cloudflare does—if it’s necessary at all—can be replicated with a cheap (or free) VPS sitting in front of your network on a VPN, and the remainder doesn’t matter for most selfhosted use cases.

I’d recommend Wireguard over OpenVPN, it’s much faster and just generally more efficient. Notably, it also handles network changes better, and reconnects in seconds rather than minutes. It seems like it would be a much better fit for your use case.