More than any other piece of self-hosted software: backups are important if you’re going to host a password manager.

I have Borg automatically backing up most of the data on my server, but around once every 3 months or so, I take a backup of Vaultwardens data and put it on an external drive.

As long as you can keep up with that, or a similar process; there’s little concern to me about screwing things up. I’m constantly making tweaks and changes to my server setup, but, should I royally fuck up and say, corrupt all my data somehow: I’ve got a separate backup of the absolutely critical stuff and can easily rebuild.

But, even with the server destroyed and all backups lost, as long as you still have a device that’s previously logged into your password manager; you can unlock it and export the passwords to manually recover.

There’s a simple solution to make everyone happy:

@bobslaede@feddit.dk I could kiss you. You’ve been invaluable my friend, thank you!

Just gave this a test: CNAME ombi.domain -> local.domain with cloudflares proxy re-enabled.

Now the HTTPS, A, and AAAA requests all receive the CNAME response and browsers are happy. I didn’t even have to modify ngnix to recognize local.domain like I thought I might.

I think I’ve found the problem:

It seems my issue is pihole being unable to block/modify dns requests for HTTPS records, which don’t match the LAN IPs pihole handed out in A/AAAA records.

I’ve disabled cloudflare proxying so they don’t have HTTPS records to serve, but I’ll have to replace pihole with a better lan DNS solution if I want to turn that back on.

Thanks. That seems to be a similar, but slightly different error. I think the below may apply though.

I believe I’ve tracked down more of my issue, but fixing it is going to be a hassle:

When cloudflare proxying is enabled, there are 3 DNS records involved; A record with cloudflares ipv4, AAAA record with cloudflares IPV6, and the key to this puzzle: an HTTPS record with cloudflares ech/https config.

With pihole I can set DNS records for A/AAAA, but I have no way of blocking/setting the HTTPS record so it gets through from cloudflare.

The LAN A/AAAA records don’t match the HTTPS record from cloudflare, so browsers freak out.

Once I disabled cloudflares proxying, I no longer get HTTPS records returned and all works as intended.

I’ll either have to keep cloudflare proxying disabled, or switch pihole out for a more comprehensive DNS solution so I can set/block HTTPS records :(

Thank you @bobslaede@feddit.dk for pointing me in the right direction.

That unfortunately did not work. I am only getting the ipv4 address now, but I still get the same ECH error in chrome 1/5 tries.

Firefox now changed errors from ‘invalid certificate’ to ‘connection is insecure but this site has HSTS’ (true). Still wont show the cert or provide any further info. (forgot to grab a screenshot before the below ‘solution’)

I’m really annoyed at this point and have just disabled cloudflare proxying for this service. That seems to have sorted it for all browsers. I may look further later, I may just say fuck it and leave it like this. Gotta walk away for a bit.

I’ll look into that next if what I’ve done doesn’t work. (see other comments)

Added an AAAA record to pihole:

ombi.mydomain.example 0000:0000::0000:0000

Now nslookup returns the correct ipv4 address, and ‘::’ as the ipv6.

We’ll see if that works.

Crap, looks like that’s exactly what it is.

Now how to fix that…

I do have external acces to Ombi via cloudflare; but the device I’m seeing this problem on is permanently connected to a VPN hosted from the same server machine as ombi/nginx with ‘block all connections without VPN’ enabled. And this testing has been done from within the same LAN.

It should never see/reach cloudflare for this service.

/edit; I’ve also disabled ‘use secure DNS’ in chrome. I host a local DNS within that lan/vpn network.

You’ve done enough, keeping it behind your routers firewall.

You could block LAN access and require a VPN connection to that specific machine if you really wanted more, but I’m not that concerned about it.

Yup. Point is; if you’re not depending on just its login page to keep it secure, there’s not a whole lot needing ‘security patches’, so I wouldn’t be all that concerned about slow updates. As long as it remains bug free, I’m happy.

And security patches

Something with the power of dockge should be behind a seprate form of authentication imo.

I only access it via VPN, it’s not exposed to WAN.

I tend to just use FolderSync myself. To avoid battery issues, I have a schedule for most folders; but my DCIM/Pictures folders sync immediately upon changes. I then have a widget on my homepage that triggers a ‘sync all’. Anytime I need files synced immediately, it’s easy enough to click that button.

Just this week, I setup Homepage to monitor my server and its various docker containers at a glance, including cpu/ram/network usage and a whole bunch of information pulled from their APIs (such as how many itemes are actively downloading via sonarr+sabnzbd, or how many queries were blocked by pihole today).

That in turn lead me too Glances, both as various widgets in Homepage as well as a stand alone tool.

Note: Homepage doesn’t come with authentication. You’ll have to handle that yourself via a reverse proxy or vpn. Glances has an optional login page you can enable, but I haven’t explored that. I access services like these by connecting to my network through OpenVPN.

Find a problem they are experiencing and introduce them to a solution they can self-host to fix it. Expand from there.

I began my self-hosting journey 7ish years ago with media piracy and a desire to watch/access my files wherever I was. Learned of Plex, then Emby, Reverse Proxies, Domains, SSL, and on and on…

Today I’m running 24+ docker containers and some miscellaneous stuff, across 3 systems; that’s always accessible via my domain/vpn.

what does not work:

• i can not ping server.local (- for testing i have to stop the systemd-resolved.service to run the dnsmasq server, or else there are port collisions, but that should not be the problem i guess. I am happy to hear your solution :))
• i can also not use ssh to log in to server.local, ip address works

Have you added “server.local” as a DNS record in your dnsmasq container, pointing to your servers LAN IP? Sounds like dnsmasq isn’t resolving that name, which would lead to both of these ‘failures’.

Oh damn, I hadn’t noticed. My setup is still functioning just fine.

There is an alternative though: Orbital-Sync

I haven’t actually used it, so I can’t say much about it; but I’ll probably look into replacing gravity-sync with that.

https://docs.pi-hole.net/guides/dns/cloudflared/

I use this to translate DNS to DoH, and use cloudflare, and quad9 upstream.

environment:
  - TUNNEL_DNS_UPSTREAM=https://1.1.1.1/dns-query,https://1.0.0.1/dns-query,https://9.9.9.9/dns-query,https://149.112.112.9/dns-query

Haven’t really noticed any DNS based lag.

Why not both?

My primary DNS is pihole on a rpi dedicated to the task; but I run a second instance of pihole via my main docker stack for redundancy. Should one or the other be unavailable, there’s a second one to pick up the slack.

I just provide both DNS IPs to LAN clients via DHCP.

Gravity Sync is a great tool to keep both piholes settings/records/lists in sync.