Custom URL stopped working

[airigami]

Suddenly, I can't connect to the web page from outside of my local network. I've had a custom URL set up since I started playing weeks ago. I checked that my DDNS service is still working. The name resolves correctly. I have the custom URL set correctly. the Caddyfile shows the correct name. Everything works when using .local. I just get a blank screen when I connect using my custom URL. Not sure what else to try. It worked fine and then, without any changes (that I'm aware of) started giving me the blank screen. I restarted services. I even rebooted. DDNS and router are still behaving properly and mapping ports right.

Thanks for any suggestions.

[mcguirepr89]

Hello! I'm really sorry to hear that you're having trouble.

It could be helpful to know the public domain where the installation should be reachable to help look into the issue.

Log wise, if you could please provide the output from the following, I'd be happy to try to take a look and see why this sudden trouble has cropped up:

journalctl --no-hostname --no-pager -n100 -ucaddy

I'm hopeful we'll get this resolved. There likely needs to just be a little time added to the systemd service to allow for better certificate maintenance. If that is what we find, I will likely submit a request to Caddy to have this default changed.

🤞

[mcguirepr89]

Update: We swapped him over to using port 80 and it is working just fine from there. He'll reboot the router later and see if port 8124 has the same trouble after that.

[ehpersonal38]

Ooh so it was a port thing? Interesting since the web page was still loading (albeit a white screen) meaning the router still was port forwarding... seems like Caddy just denied the requests for some reason.

[mcguirepr89]

Yeah that white screen means the request headers don't match the site-address, so somewhere in that forwarding SOMETHING about the header changed. Localhost access worked fine (@airigami provided me access to SSH, so I verified with a dynamic SSH tunnel and a SOCKS v5 proxy via FireFox and everything was served fine there). The only changes were removing the nonstandard port 8124 from the Caddyfile, changed the port forwarding on his router, and reloaded Caddy. The real test will be to see what happens after the router reboot -- (with your networking savvy, what guesses would you make? You WON'T hurt me feelings if your suppositions are super different from mine)

[ehpersonal38]

Woah! I didn't even know dynamic SSH tunnels were a thing, that's super cool. It's kind of interesting to me that it's integrated with SSH though, I always viewed SSH as strictly a remote shell thing, not a proxy suite.

But anyways, this is clearly a case of the 16th octet of the IPv4 header being flummoxed without accounting for NAT traversal through BGP, something that should have been encapsulated within a TCP handshake, port forwarded to the inverse port, and link-aggregated through the routing table to restore the HTTP headers. No, I seriously have no idea. Ghosts still? 😆

[mcguirepr89]

Woah! I didn't even know dynamic SSH tunnels were a thing, that's super cool. It's kind of interesting to me that it's integrated with SSH though, I always viewed SSH as strictly a remote shell thing, not a proxy suite.

Yes it's super helpful. If you want to play with it yourself, you can view your BirdNET-Pi as "localhost" from your laptop via:

ssh -D 1234 mybirdnetpiuser@mybirdnetpi.local

Then go over to FireFox > "Settings" > scroll all the way down to "Network Settings" and configure the proxy as such:

and then going to "localhost" will be the BirdNET-Pi's localhost. (I had to use these tunnels all the time in my former job to troubleshoot things to see if the issues were on the webserver or on the network).

Pretty nifty ;)
I was so stoked on that answer and you totally had me all the way to the end!!! hahahahaha