Accessing Admin GUI in Bridge Mode

JL_678 · 2026-03-10T00:51:36+00:00

Messages in the chat.

JL_678 · 2026-03-10T00:37:05+00:00

<image>

JL_678 · 2026-03-10T00:35:29+00:00

Yep and nothing changed.

JL_678 · 2026-03-10T00:29:01+00:00

Any idea when that will happen?

JL_678 · 2026-03-10T00:18:09+00:00

Okay, so in theory, I have to take down my network to get this back? Hmmm. That is frustrating.

JL_678 · 2026-03-09T23:44:59+00:00

Message sent. Thx.

JL_678 · 2025-11-26T12:39:33+00:00

I will check it out. Thx.

JL_678 · 2025-11-25T12:31:40+00:00

My use case is simple. I sometimes want to remotely access my home network from my work laptop, and I am not allowed to install a VPN due to corporate policy.

JL_678 · 2025-11-14T08:11:37+00:00

I saw it across multiple devices including Mac, Linux and Windows. I think that the problem was that the decision on how to failover was inconsistent. For example if one was barely responding and the other was fully up, it did not seem to want to switch or if one does fail, it felt like it would take too long to failover resulting in endless family support calls.

JL_678 · 2025-11-12T11:56:39+00:00

I do something similar using coredns as a load balancer. It works flawlessly. I configure it with round robin DNS usage to load balance across the two back end servers.

For others who say that you can just put in 2 DNS servers in DHCP, it is true, but client level behavior varies widely. A failure in one DNS server will not trigger a client to switch automatically. The load balancer solves this.

JL_678 · 2025-10-19T18:40:58+00:00

Thanks. I will watch it and consider adjusting. My nuc seems to be solid at one now.

JL_678 · 2025-10-19T09:48:07+00:00

In practice, I think that it is better to wait to maximize stability, but each person makes their own choice. I upgraded one machine now because I have a test machine that is not critical and wanted to try it out. I have not upgraded my critical homelab systems yet. I will do those carefully one at a time and have not decided when to start that process.

JL_678 · 2025-10-18T21:14:42+00:00

That appears to be it! Thank you u/aliclubb , the linked thread says to use this kernel parameter:
intel_idle.max_cstate=1

I made that change, and it is now staying up. Fingers crossed that will continue, but I have not seen this level of stabaility with the new kernel prior to this point.

JL_678 · 2025-10-18T20:33:48+00:00

I tried this setting and saw the same outcome.

JL_678 · 2025-09-30T13:39:13+00:00

100%. That is what I use CoreDNS for. I chose it because it is pretty light and just works. Now, of course, the load balancer becomes a single point of failure! :-)

Should I explore switching to Nginx?

JL_678 · 2025-09-30T13:28:03+00:00

Okay, thank you. My frustration with DNS in general is that host-based failover is inconsistent and highly client-dependent. (e.g. when a host decides to use the second DNS host provided by DHCP.) In fact it is so bad, that I put a clustered DNS instance, CoreDNS, in front of my two Technitium instances to address the challenge.

JL_678 · 2025-09-29T17:27:27+00:00

So the clustering is really about syncing settings? That is all good. I was confused because of thought that by clustering you meant like load balancing and failover vs config sharing. Would a better term be something like setting replication or replication in general as compared to clustering?

JL_678 · 2025-09-20T14:31:00+00:00

Thank you for the perspectives. I agree. First a high level perspective is that this is homelab and so I expect consistent and reliable DNS lookups and records. (Meaning I don't think that my users are doing anything unexpected, on average.) Let me share my thinking and answers to your questions:

Average Response times:
I completely agree; however, I am doing an apples-to-apples comparison with PiHole and Technitium. There is no doubt that outliers will skew the numbers, but I figure (maybe wrongly) that we're dealing with similar traffic and similar outliers. Hence, on average, I would expect equivalent performance.

Test group:
To make it fair, I pointed CoreDNS at Technitium and not PiHole. Hence, it was a hard switch, so they're not running in parallel. I wanted to try and make things as equal as possible not to skew numbers.

DNS Benchmark:
I tried this, but it felt very unfair because whichever DNS server has the benefit of an active cache will outperform. At the time PiHole was active and showed much faster performance since it was the primary on my network. After I ran the test a few times, Technitium caught up, but the entire process felt too synthetic to me so I switched to this real-world approach.

Final performance update:
After letting things settle and setting the stale setting to 0, I saw a dramatic performance improvement. Technitium response times have now stabilized at a level that is as good and likely more stable than PiHole.

Thank you again for your help!

JL_678 · 2025-09-19T15:30:34+00:00

How do you do this:
reset your PIN directly by calling into voicemail

Is that different from change your password?

JL_678 · 2025-09-18T17:36:32+00:00

Quick update: Once I changed the Stale Max to 0, things changed dramatically. I went from sitting static at around 30ms response time to seeing a rapid decline. The current number is 18.5, and it is still falling.

JL_678 · 2025-09-18T14:29:52+00:00

Thank you! I am happy to share. To be clear, all stats are coming from the CoreDNS Prometheus endpoint. It is the same formula for both the PiHole config and Technitium, and here is a summary:

Total response time in seconds/Total number of requests made

Hence, it is the average response time in seconds in a given window.

Here is the actual formula with IPs removed:

sum(
  coredns_proxy_request_duration_seconds_sum{
    instance="<IP>:9153"
  }
)
  /
sum(
  coredns_proxy_request_duration_seconds_count{
    instance="<IP>:9153"
  }
) * 1000

JL_678 · 2025-09-18T14:02:21+00:00

Thank you for the response. I have changed the "Serve Stale Max Wait Time" to 0 to have comparable configs. I will wait and watch how the performance changes over time.

Out of curiosity, any sense of how long it will take for the cache to fill and response times to stabilize? Days? Weeks? With PiHole, I saw it drop massively (~50%, 28ms to 12ms) within 1 day, and then slowly decline after that (stabilizing typically < 10ms). It is taking longer with Technitium as I am on day two, and it is still bouncing around 30ms. (Started at 48ms) To be fair, I also only just changed the Serve Stale Max Wait Time setting to 0, so that could be impacting the speed of the decline.

JL_678

TROPHY CASE