A lemm.ee refugee ;)

  • 6 Posts
  • 58 Comments
Joined 11 months ago
cake
Cake day: June 6th, 2025

help-circle
  • Are you sure L2 is 192.168.1.0/24 and not something larger that includes 192.168.30.0, e.g.: 192.168.0.0/16?

    Bro/Mam/Sir! Bravo!

    You absolutely fixed it in one line. My friend stupidly set the netmask as /16 even though he doesn’t need such a large IP pool. I changed it and now WG is working.

    There is only one issue remaining, that is my local DNS queries are not being answered on my laptop (On phone + WG, it’s working). But it’s working when I direct my dig queries.

    dig server.lan = not working

    dig @dns.lan server.lan = working

    But ping dns.lan is working. I suspect my DNS IP has not properly percolated to my laptop.

    Thanks a lot!!


  • I’m terribly sorry. I have fixed the case numbers with the item numbers.

    I suspect at least part of the problem is that Android does not tunnel hotspot client traffic.

    On android, it works fine in all scenarios. The Linux laptop is causing issues. I checked another case (Case 5). If the client is Windows, everything works fine. I’ll try to replicate this on another linux machine and check.

    WG running on the Firestick

    I had to search a lot but I found a client which works on the first gen Firestick. Check https://airvpn.org/. They still release a compatible WG client on the ancient android/Amazon device.



  • Hello there. I perfectly understand the risks of my setup. Since it’s a commercial off-the-shelf router, i can’t run a reverse proxy on it, so this is the best that i can do (other than VLANs). It’s also a private network, so I guess it’s fine.

    I used a bit of AI which said that such embedded devices don’t work with reverse proxies. Finding which exact parameters as respected by the router will be time-consuming and the end result is not that great.












  • I have tried this, but unfortunately, it did not work. I have tried this suite of commands

    login.router.lan {
        reverse_proxy 192.168.1.1:80 {
            # Preserve original host and scheme
            header_up Host {upstream_hostport}
            header_up X-Forwarded-Proto {http.request.scheme}
            header_up X-Forwarded-Host {http.request.host}
            header_up X-Forwarded-For {http.request.remote.host}
    
            # Keep cookies intact
            header_up Cookie {http.request.header.Cookie}
            header_down Set-Cookie {http.response.header.Set-Cookie}
    
            # Preserve Origin/Referer for CSRF tokens
            header_up Origin https://{http.request.host}
            header_up Referer https://{http.request.host}{http.request.uri.path}
        }
    }
    

    Info: My caddy uses HTTPS but the router login page is HTTP. Not sure if this is relevant.


  • 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.








  • I will agree that my advice is bad.

    I myself run all my services over wireguard. But I run ssh natively though but with extra hardening (fail2ban/sshkey/no default port/max retries, etc). Plus my IP changes every 24 hours. However, I did learn how to setup online services and this can be a stepping stone.

    If one is experimenting, exposing the port is fine (temporarily). But if someone is running a service 24/7 over the internet, and the person does not have any cyber security acumen, wireguard is the clear winner.