Hello all,

I figured that a chunk of the selfhost community is using Caddy, so decided to post my query here. I am a novice in Caddy, so I might be saying some incorrect terms.

Some information

  • The router and the host running Caddy, are different machines
  • The router page is running HTTP, but I am accessing it via HTTPS through Caddy
  • Caddy is running via Docker.

I have a couple of services running on a host, so I access them via Caddy’s reverse proxy. Now I am also trying to access my router login via the same reverse proxy. This is what the router entry in the caddyfile looks like

.
.
{
    local_certs
}
login.router.lan {
	reverse_proxy 192.168.1.1:80
}
.
.

With this entry, I can access the login page. However, when I enter the password, I feel like it’s attempting to login but then it just comes back to the original login page. When I access it directly, the login is successful. I also have Pihole running and the Pihole login process works fine. So I suspect that the router login page is expecting some extra information from Caddy to forward it to the login page.

After some searching online and some LLM wrangling, I figured it’s some cookie issue or my login page is expecting a certain host.

What should I add to my Caddyfile so that the login redirect works?

Edit: Clarification! Everything is behind wireguard. Nothing is exposed to public (other than wireguard). I only access it within my home. The router login page cannot be accessed from outside.

  • UnpledgedCatnapTipper@piefed.blahaj.zoneEnglish
    1·
    8 hours ago

    Does accessing your router page via caddy work when you’re actually on your home network and not accessing it via wireguard? Have you tried a different web browser to rule out your LLM suggested cookie issues entirely?

    • xavier666@lemmy.umucat.dayOPEnglish
      1·
      8 hours ago

      Does accessing your router page via caddy work when you’re actually on your home network

      Unfortunately no, which rules out an issue with wireguard.

      Have you tried a different web browser to rule out your LLM suggested cookie issues

      It’s not the stale cookie issue which goes away when opening a website in incognito. I think it expects the cookie to have the original host information.

      Let me paste the list of issues the LLM mentioned. The following section is from the LLM

      <LLM>

      1. The router’s web UI expects the original hostname (e.g., 192.168.0.1) and builds redirects or CSRF tokens based on it. Caddy sends its own host (myproxy.example.com).
      2. Authentication cookies are set for the original domain and may be dropped or rewritten by the proxy, causing the server to think the user is unauthenticated.
      3. The router returns Location: http://192.168.0.1/… which points the browser back to the internal address, bypassing the proxy.
      4. Tokens are generated using the Origin or Referer header; the proxy changes these, making the token invalid on POST.
      5. The router forces HTTPS or blocks HTTP when it sees a mismatch, and Caddy may be terminating TLS while the upstream expects plain HTTP.
      6. Some admin UIs use WebSocket for status updates; if Caddy doesn’t forward the upgrade, the page may reload to the login screen.
      7. The router’s UI may be served from / but expects relative paths; Caddy’s uri rewrite can break those links.

      </LLM>

      It has also mentioned some solutions for each cause. But I don’t want to blindly apply them without knowing what is wrong.