First, thank you in advance.
I’m having trouble with exposing my server, I think what I need is a better understanding, as opposed to technical help (though that would be appreciated)
At the moment I’m using the linuxserver.io suite of applications. I’ve got SWAG set up with DuckDNS, and I’m trying to set up Jellyfin and other applications. (they’re all in the same compose.yaml).
I can access my applications on an external network via
<user>.duckdns.org:<port>
and it works fine (but no https).
Within my home network I can access jellyfin.<user>.duckdns.org - the https is valid and everything is working fine.
I suspect this means my router is not set up correctly? I’m using OpenWRT. What am I doing wrong?
This would suggest port 443 is not being exposed externally. You might try using a CLI tool like “curl” which is fairly verbose about how it is connecting to a given URL, as part of trying to download the link. If given an HTTPS URL that doesn’t work, the output should help point at the issue.
Thanks, this put me on the right track (I think).
I still can’t determine what is wrong exactly.
I can access my other services with
<user>.duckdns.org:<port>But for some reason ports 80 and 443 are exclusively failing to connect, despite all port forwarding rules on my router being identical, and my server’s firewall permitting access to those ports.
Could it be some kind of security on my router or server is intercepting the connection?
I’m still trying to understand exactly what you do have working. You have other services exposed by port numbers, and they’re accessible in the form <user>.ducksns.org:<port> with no problems there. And then you have Jellyfin, which you’re able to access at home using https://jellyfin.<user>.duckdns.org without problems.
But the moment you try accessing that same URL from an external network, it doesn’t work. Even if you use HTTP with no S, it still doesn’t connect. Do I understand that correctly?
Thanks again for trying to help me, it’s really appreciated, I’m tearing my hair out.
Externally, I can access all services via their ports, except SWAG (port 80 and 443).
Internally, (from my PC to my server on the same local network) I can access:
jellyfin.<user>.duckdns.org(secure)<user>.duckdns.org:8096(not secure)<user>.duckdns.org:80- routes to the SWAG homepage at https://<user>.duckdns.org (secure)<user>.duckdns.org:443- as above#.
If I try to use curl on
<user>.duckdns.orgI get:<user>.duckdns.org:80was resolved.Thank you for that detailed description. I see two things which are of concern: the first is the IPv6 network unreachable. The second is the lost IPv4 connection, as opposed to a rejection.
So staring in order, the machine on the external network that you’re running curl on, does it have a working IPv6 stack? As in, if you opened a web browser to https://test-ipv6.com/ , does it pass all or most tests? An immediate “network is unreachable” suggests that external machine doesn’t have IPv6 connectivity, which doesn’t help debug what’s going on with the services.
Also, you said that all services that aren’t on port 80 or 443 are working when viewed externally, but do you know if that was with IPv4 or IPv6? I use a browser extension called IPvFoo to display which protocol the page has loaded with, available for Chrome and Firefox. I would check that your services are working over IPv6 equally well as IPv4.
Now for the second issue. Since you said all services except those on port 80, 443 are reachable externally, that would mean the IP address – v4 or v6, whichever one worked – is reachable but specifically ports 80 and 443 did not.
On a local network, the norm (for properly administered networks) is for OS firewalls to REJECT unwanted traffic – I’m using all-caps simply because that’s what I learned from Linux IP tables. A REJECT means that the packet was discarded by the firewall, and then an ICMP notification is sent back to the original sender, indicating that the firewall didn’t want it and the sender can stop waiting for a reply.
For WANs, though, the norm is for an external-facing firewall to DROP unwanted traffic. The distinction is that DROPping is silent, whereas REJECT sends the notification. For port forwarding to work, both the firewall on your router and the firewall on your server must permit ports 80 and 443 through. It is a very rare network that blocks outbound ICMP messages from a LAN device to the Internet.
With all that said, I’m led to believe that your router’s firewall is not honoring your port-forward setting. Because if it did and your server’s firewall discarded the packet, it probably would have been a REJECT, not a silent drop. But curl showed your connection timed out, which usually means no notifications was received.
This is merely circumstantial, since there are some OS’s that will DROP even on the LAN, based on misguided and improper threat modeling. But you will want to focus on the router’s firewall, as one thing routers often do is intercept ports 80 and 443 for the router’s own web UI. Thus, you have to make sure there aren’t such hidden rules that preempt the port-forwarding table.
Appreciate all the help this far.
I think this issue is either application or OS related.
I’ve been wanting to wipe my server and start fresh for a while to work with NixOS.
As a beginner, I’m sure I’ve changed some obscure setting, somewhere, which has just broken everything. I don’t think it’s worth it to diagnose.
But definitely learned a lot in the process of following your advice, so thanks heaps :)
Good luck with your endeavors! Always keep in mind that when debugging a complex problem, try isolating individual components and testing them individually. This can be as easy as swapping a web application with the Python SimpleHTTPServer to validate firewall and reverse proxy configuration.
I’ll give this a go soon