Most DNS queries are UDP.

I’d do a modified scream test and change old.domain to something like 1.2.3.4. Then run sudo netstat or ss with -tpn, grepping for 1.2.3.4.

Or something like grep -r old.domain /etc.

Yep, that would work fine for the first line of defense. Eventually, you can expand it to copy, replicate, or drive swap the onprem backups offsite somewhere (e.g., cloud, office, or family member) if you want to protect your data from site loss (e.g., house fire).

The only thing missing is a good backup.

If you are storing anything important – especially Immich and Vaultwarden data – you should have a good offsite protection strategy. And even the HASS config should be backed up with versioning because rebuilding from scratch could be painful once you get deep into it.

I’ll let others chime in on possible good backup options because I use Veeam and Azure, which really isn’t in the spirit of this community, and I’d be interested in good open source options myself.

Also, RAID (mirroring) is NOT a backup.

The easiest way that doesn’t affect the main network would be to use a travel router. Its WAN IP would be the private IP it gets from the main network (over wireless since that’s your only option). And it would NAT your network onto that IP and then you can do whatever you want on your network.

I’m not sure if that Mikrotik router will do this but it might. You basically need something that can connect to an SSID and use that interface as its WAN interface. The wireless factor here is really limiting your choices. If you had a wired uplink to the main network you could use any router/gateway/firewall you wanted. You could also use an AP in bridge mode to connect to the main network’s SSID and wire it to the WAN port of any router of your choice.

You don’t really need to use VLANs to separate your network from the main network unless you want to share any of the same layer 2 segments (basically wired Ethernet) while keeping it isolated. But it doesn’t really sound like that applies in your scenario. Of course using VLANs within your network would still make sense if that applies (for example, to separate your server traffic from your IoT traffic).

Yep that’s how I have Syncthing set up. All global and local discovery disabled, no firewall ports open on the clients, no broadcasting, no relay servers. Just syncing through a central server which maintains versioning and where the backups run. Works like a charm.

Not that it’s my first recommendation for security reasons, and I would never do this in prod, but you can just add the self-signed cert to the local trusted root CA store and it should work fine. No reg changes needed.

If you do this, put it in the store of the user running the client, not LocalMachine. Then you just need to make sure you connect as something in the cert’s SAN list. An IP might work (don’t know since I never try to put IPs in the SAN list), but just use a hosts entry if you can’t modify local DNS.

Edit: after reading the full OP post (sorry), I don’t think it’s necessarily the self-signed cert. If the browser is connecting with https:// and presenting a basic auth prompt, then https is working. It almost sounds like there is a 301/302 redirect back to http after login. Check the Network tab of the browser’s dev pane (F12) to see what is going on.

This is like the epitome of the XY Problem.

https://xyproblem.info/

If you’re sure you’ve got a DNS entry for the Pihole FQDN pointing at Traefik, open the dev panel in your browser (F12), switch it to the Network tab, and visit the pihole URL.

See if you get anything back and especially take note of the HTTP status codes.

Can you see the router and service in the Traefik dashboard and do they show any errors there?

I think you’re close.

You need to change service: pihole-rtr to service: pihole-svc.

Do I have to redefine all of the same information I did in my Traefik yml but in this separate config.yml?

No, you just need to reference it like you have. Define once, reference many.

No worries for the question. It’s not terribly intuitive.

The configs live on the Traefik server. In my static traefik.yml config I have the following providers section, which adds the file provider in addition to the docker provider which you likely already have:

providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedByDefault: false
  file:
    directory: /config
    watch: true

And in the /config folder mapped into the Traefik container I have several files for services external to docker. You can combine them or keep them separate since the watch: true setting tells it to read in all files (and it’s near instant when you create them, no need to restart Traefik).

Here is my homeassistant.yml in that folder (I have a separate VM running HASS outside of Docker/Traefik):

http:
  routers:
    homeassistant-rtr:
      entryPoints:
      - https
      service: homeassistant-svc
      rule: "Host(`home.example.com`)"
      tls:
        certResolver: examplecom-dns

  services:
    homeassistant-svc:
      loadBalancer:
        servers:
          - url: "http://hass1.internal.local:8123"

Hope this helps!

I use the Traefik file provider for this.

https://doc.traefik.io/traefik/providers/file/

It picks up all my .yml configs in the watched folder which define the routers and services external to Docker.

I know plenty account SNI already, but thanks. You might want to study more yourself, since we’re being condescending.

https://blog.cloudflare.com/encrypted-sni/

So now your ISP sees all of your queries instead of CF. (Assuming the cloudflared option is using DoH)

I’ll trust Cloudflare over Comcast/AT&T/etc. any day of the week.

I believe you. I’m just saying their non-firewalls (i.e., switches and APs) don’t have that limitation.

My firewall is a Fortigate 60F.

I would never use their firewalls/gateways, but their switches are pretty good for the price and their APs are decent (although tbh after 3 generations my next AP will likely be an enterprise Aruba).

That said, I still use Unifi in docker, everything is up to date, and nothing is requiring a sign-in to the cloud. Am I missing something? If it’s just the firewalls, then I’m not surprised since I’ve never been remotely tempted to use them, but it sure isn’t all of their devices.

In that case, if CF is taking to Traefik and not the actual origin server, you just need to forget about the origin certs altogether and use LE certs in Traefik.

If you, Traefik, and your origin server are on the same network, then it’s going to be one hop regardless of whether you’re hitting the Traefik proxy or the origin server. If Traefik is serving up the origin server’s cert and not the LE cert, then Traefik is misconfigured to pass through instead of proxy, but I’m still not sure that’s the case as it’s almost harder to configure it that way than the correct way as a proxy.

What IP:port is your origin server listening on, what IP:port is Traefik listening on, and how is Traefik configured to reach the origin server?

You said Traefik is getting certs from Cloudflare, but do you mean it’s getting Let’s Encrypt certs using a CF DNS challenge? And if that is the case, then your browser should trust the Traefik endpoint since LE certs are publicly trusted.

Are you sure you’re hitting Traefik when you get a cert warning? You need to update your internal DNS if not.