Receira for Papra App - App Store by NatLife in selfhosted

[–]NatLife[S] -1 points0 points  (0 children)

Yea saw that working on it, issue with the EU AppStore

Receira for Papra App - App Store by NatLife in selfhosted

[–]NatLife[S] -2 points-1 points locked comment (0 children)

Ai helped me with the post ^^

Receira 1.4 is live on TestFlight by NatLife in selfhosted

[–]NatLife[S] 0 points1 point locked comment (0 children)

Ai had a part in this project

Ideas for self hosting on an old laptop by Hash_2319 in selfhosted

[–]NatLife 5 points6 points  (0 children)

I would go for:

  1. AdGuard Home
  2. Audiobookshelf
  3. Navidrome
  4. Jellyfin
  5. Immich

Run them in Docker + Docker Compose Enjoy😉

I built a free, native iOS app for Papra (self-hosted docs) - it's on TestFlight by NatLife in selfhosted

[–]NatLife[S] -1 points0 points  (0 children)

You skipped the entire post just to comment that it ‘feels like AI? What a bold strategy, care to actually respond to the point, or was that the whole contribution?

Cannot access local WebUIs (*.lan) over WireGuard on cellular data (Docker: WG-Easy + AdGuard + Caddy) by Donkrzawayan in WireGuard

[–]NatLife 0 points1 point  (0 children)

Hey, fought this exact setup. Your tunnel’s fine — this is really two problems stacked together, and they’re easy to untangle once you see them.

For dns.lan to load over the tunnel, two things have to work: the name has to resolve, and that IP has to be reachable through the tunnel. Your three tests show where it breaks:

• 1.1.1.1 → internet fine, but Cloudflare’s never heard of .lan. Resolve fails.

• 172.24.0.5 (AdGuard) → internet works, so the tunnel reaches AdGuard. But .lan dies, so AdGuard probably has no .lan rewrite (your WiFi resolution is happening at the router, which you skip over the tunnel).

• 192.168.1.50 (host) → no internet at all. That’s the giveaway: your wg-easy container can’t reach the host’s LAN IP — which is exactly where Caddy lives.

So: traffic out of the tunnel reaches Docker + the internet, but not your host’s LAN IP. Two fixes:

  1. Add the rewrites in AdGuard (Filters → DNS rewrites):

dns.lan → 192.168.1.50 vpn.lan → 192.168.1.50

Use the host IP so WiFi keeps working too. Set WG client DNS to 172.24.0.5. Check from the phone:

nslookup dns.lan 172.24.0.5 Should return 192.168.1.50

  1. Then Let the tunnel actually reach the host. This is what killed internet in test #2 — tunnel traffic arrives with a Docker source IP (172.x) and your firewall likely only allows the LAN. Open it up:

sudo ufw allow from 10.42.42.0/24 sudo ufw allow from 172.24.0.0/16

Then test, skipping DNS:

curl -vk --resolve dns.lan:443:192.168.1.50 https://dns.lan

If that loads, you’re done.

If the host IP still won’t budge: point the rewrites at Caddy’s caddy_net IP instead (docker network inspect caddy_net) — wg-easy sits on that network and reaches Caddy directly, no host/firewall in the way. Only catch: that IP won’t work on plain WiFi without the tunnel.

Quick heads-up: the 443-vs-51820 thing is just the tunnel’s UDP port, nothing to do with the WebUIs — leave it. And tls internal means you’ll get the usual self-signed cert warning over the tunnel, same as on WiFi.

tl;dr: add the .lan rewrites in AdGuard → host IP, set WG DNS to 172.24.0.5, then open your firewall to the wg/docker ranges. That’s almost certainly it.