Weather station, terrestrial/satellite TV DVR (TVHeadend), Git repository (Forgejo for a nice web UI, cgit for a classic UI), DNS resolver.

For my own networks, I’ve been using IPv6 subnets for years now, and have NAT64 translation for when they need to access Legacy IP (aka IPv4) resources on the public Internet.

Between your two options, I’m more inclined to recommend the second solution, because although it requires renumbering existing containers to the new subnet, you would still have one subnet for all your containers, but it’s bigger now. Whereas the first solution would either: A) preclude containers on the first bridge from directly talking to containers on the second bridge, or B) you would have to enable some sort of awful NAT44 translation to make the two work together.

So if IPv6 and its massive, essentially-unlimited ULA subnets are not an option, then I’d still go with the second solution, which is a bigger-but-still-singular subnet.

This doesn’t answer OP’s question, but is more of a PSA for anyone that seeks to self-host the backend of an E2EE messaging app: only proceed if you’re willing and able to upkeep your end of the bargain to your users. In the case of Signal, the server cannot decrypt messages when they’re relayed. But this doesn’t mean we can totally ignore where the server is physically located, nor how users connect to it.

As Soatok rightly wrote, the legal jurisdiction of the Signal servers is almost entirely irrelevant when the security model is premised on cryptographic keys that only the end devices have. But also:

They [attackers] can surely learn metadata (message length, if padding isn’t used; time of transmission; sender/recipients). Metadata resistance isn’t a goal of any of the mainstream private messaging solutions, and generally builds atop the Tor network. This is why a threat model is important to the previous section.

So if you’re going to be self-hosting from a country where superinjunctions exist or the right against unreasonable searches is being eroded, consider that well before an agent with a wiretap warrant demands that you attach a logger for “suspicious” IP addresses.

If you do host your Signal server and it’s only accessible through Tor, this is certainly an improvement. But still, you must adequately inform your users about what they’re getting into, because even Tor is not fully resistant to deanonymization, and then by the very nature of using a non-standard Signal server, your users would be under immediate suspicion and subject to IRL side-channel attacks.

I don’t disagree with the idea of wanting to self-host something which is presently centralized. But also recognize that the network effect with Signal is the same as with Tor: more people using it for mundane, everyday purposes provides “herd immunity” to the most vulnerable users. Best place to hide a tree is in a forest, after all.

If you do proceed, don’t oversell what you cannot provide, and make sure your users are fully abreast of this arrangement and they fully consent. This is not targeted at OP, but anyone that hasn’t considered the things above needs to pause before proceeding.

I mean, at the USA average price of electricity of $0.13 per kWh, then for a halving of 70 Watts, it’s about 11 cents per day, or $40 per year. But at the California average price of $0.35, then the savings is 29 cents per day, or $107 per year.

That’s not small money, especially if it’s free to make these gains by ripping out unneeded functionality. But the point is taken that it’ll be hard to find savings from older hardware, which simply didn’t prioritize energy efficiency.

But how do they connect to your network in order to access this web app? If the WiFi network credentials are needed to access the network that has the QR code for the network credentials, this sounds like a Catch 22.

Also, is a QR code useful if the web app is opened on the very phone needing the credentials? Perhaps other phones are different, but my smartphone is unable to scan a QR code that is on the display.

I’m not immediately understanding what the user scenario/story is. Would a family member open this web app on a desktop computer, in order to obtain the WiFi credentials to configure their phone or tablet?

Typically, business-oriented vendors will list the hardware that they’ve thoroughly tested and will warranty for operation with their product. The lack of testing larger disk sizes does not necessarily mean anything larger than 1 TB is locked out or technically infeasible. It just means the vendor won’t offer to help if it doesn’t work.

That said, in the enterprise storage space where disks are densely packed into disk shelves with monstrous SAS or NVMeoF configurations, vendor specific drives are not unheard of. But to possess hardware that even remotely has that possibility kinda means that sort of thing would be readily apparent.

To be clear, the mobo has a built-in HBA which you’re using, or you’re adding a separate HBA over PCIe that you already have? If the latter, I can’t see how the mobo can dictate what the HBA supports. And if it’s in IT mode, then the OS is mostly in control of addressing the drive.

The short answer is: you’ll have to try it and find out. And when you do, let us know what you find!

Congrats on the acquisition!

DL380 G9

Does this machine have its iLO license? If so, you’re in for a treat, if you’ve never used IPMI or similar out-of-band server management. Starting as a glorified KVM, it then has full power control authority (power on/off, soft reset, hard reset), either a separate or shared Ethernet connection, virtual CD and USB, SNMP reporting, and other whiz-bang features. Used correctly, you might never have to physically touch the machine after installation, except for parts replacement.

What is your go-to place to source drive caddies or additional bays if needed?

When my Dell m1000e was missing two caddies, I thought about buying a few spares on eBay. But ultimately, I just 3d printed a few and that worked fine.

Finally, server racks are absurdly expensive of course. Any suggestions on DIY’s for a rack would be appreciated.

I built my rack using rails from Penn-Elcom, as I had a very narrow space I wanted to fit my machines. Building an open-frame 4-post rack is almost like putting a Lego set together, but you will have to take care to make sure it doesn’t become a parallelogram. That is, don’t impart a sideways load.

Above all, resist the urge to get by with a two-post rack. This will almost certainly end in misery, considering that enterprise servers are not lightweight.

I agree with this comment, and would suggest going with the first solution (NAT loopback, aka NAT hairpin) rather than split-horizon DNS. I say this even though I have a strong dislike of NAT (and would prefer to see networks using flat IPv6 addresses, but that’s a different topic). It should also be fairly quick to configure the hairpin.

Specifically, problems arise when using DNS split-horizon where the same hostname might resolve to two different results, depending on which DNS nameserver is used. This is distinct from some corporate-esque DNS nameservers that refuse to answer for external requests but provide an answer to internal queries. Whereas by having no “single source of truth” (SSOT) for what a hostname should resolve to, this will inevitably make future debugging harder. And that’s on top of debugging NAT issues.

Plus, DNS isn’t a security feature unto itself: successful resolution of internal hostnames shouldn’t increase security exposure, since a competent firewall would block access. Some might suggest that DNS queries can reveal internal addresses to an attacker, but that’s the same faulty argument that suggests ICMP pings should be blocked; it shouldn’t.

To be clear, ad-blocking DNS servers don’t suffer from the ails of split-horizon described above, because they’re intentionally declining to give a DNS response for ad-hosting hostnames, rather than giving a different response. But even if they did, one could argue the point of ad-blocking is to block adware, so we don’t really care if SSOT is diminished for those hostnames.

I previously proffered some information in the first thread.

But there’s something I wish to clarify about self-signed certificates, for the benefit of everyone. Irrespective of whichever certificate store that an app uses – either its own or the one maintained by the OS – the CA Browser Forum, which maintains the standards for public certificates, prohibits issuance of TLS certificates for reserved IPv4 or IPv6 addresses. See Section 4.2.2.

This is because those addresses will resolve to different machines on different networks. Whereas a certificate for a global-scope IP address is fine because it should resolve to the same destination. If certificate authorities won’t issue certs for private IP addresses, there’s a good chance that apps won’t tolerate such certs either. Nor should they, for precisely the reason given above.

A proper self-signed cert – either for a domain name or a global-scope IP address – does not create any MITM issues as long as the certificate was manually confirmed the first time and added to the trust store, either in-app or in the OS. Thereafter, only a bona fide MITM attack would raise an alarm, the same as if a MITM attacker tries to impersonate any other domain name. SSH is the most similar, where trust-on-first-connection is the norm, not the outlier.

There are safe ways to use self-signed certificate. People should not discard that option so wontonly.

After reviewing the entire thread, I have to say that this is quite an interesting question. In a departure from most other people’s threat models, your LAN is not considered trusted. In addition, you’re seeking a solution that minimizes subscription costs, yet you already have a VPN provider, one which has a – IMO, illogical – paid tier to allow LAN access. In my book, paying more money for a basic feature is akin to hostage-taking. But I digress.

The hard requirement to avoid self-signed certificates is understandable, although I would be of the opinion that Jellyfin clients that use pinned root certificates are faulty, if they do not have an option to manage those pinned certificates to add a new one. Such certificate pinning only makes sense when the client knows that it would only connect to a known, finite list of domains, and thus is out-of-place for Jellyfin, as it might have to connect to new servers in future. For the most part, the OS root certificates can generally be relied upon, unless even the OS is not trusted.

A domain name is highly advised, even for internal use, as you can always issue subdomains for different logical network groupings. Or maybe even ask a friend for a subdomain delegation off of their domain. As you’ve found, without a domain, TLS certificates can’t be issued and that closes off the easy way to enable HTTPS for use on your untrusted LAN.

But supposing you absolutely do not want to tack on additional costs, then the only solution I see that remains is to set up a private VPN network, one which only connects your trusted devices. This would be secure when on your untrusted LAN, but would be unavailable when awat from home. So when you’re out and about, you might still need a commercial VPN provider. What I wouldn’t recommend is to nest your private VPN inside of the commercial VPN; the performance is likely abysmal.

Ctrl Alt Speech: a podcast by TechDirt’s Mike Masnick (who coined the term “Streisand Effect”) about online speech and content regulation, and how it’s not at all a simple nor straightforward task.

Feed: https://feeds.buzzsprout.com/2315966.rss

Soatok’s Dhole Moments: a blog on cryptography and computer security, with in-depth algorithm discussions interspersed with entertaining furry art. SFW. Also find Soatok on Mastodon.

Feed: https://soatok.blog/feed/

Molly White’s Citation Needed newsletter: critiques of cryptocurrency, regulations, policies, and news. Available as a podcast too. Also find Molly White on Mastodon. She also has a site dedicated to cryptocurrency disasters.

Feed: https://www.citationneeded.news/rss/

Feed: https://www.web3isgoinggreat.com/feed.xml