Having a lot of trouble accessing ports 80 and 443 on my home network

[telepathicChimp]

Hi everyone.

I have been able to successfully set up a reverse proxy on a remote server to allow access to my Raspberry Pi from the general internet. That hasn't been a problem. What has been excruciating is finding out that apparently, I am not able to access ports 80 and 443, even with port forwarding established. Just take a look at my router's port-forwarding configuration:

---

Service Name: Jellyfin Server
Service Type: TCP
Internal Port(s): 8096~8096
External Port(s): 8096~8096
Server IPv4: 49.57.50.46 

Service Name: HTTP
Service Type: TCP/UDP
Internal Port(s): 80~80
External Port(s): 80~80
Server IPv4: 192.168.0.45
Server IPv6: 2601:47:4980:15b0:0:0:0:b7ca 

Service Name: HTTPS
Service Type: TCP/UDP
Internal Port(s): 443~443
External Port(s): 443~443
Server IPv4: 192.168.0.45
Server IPv6: 2601:47:4980:15b0:0:0:0:b7ca 

Service Name: RPI SSH
Service Type: TCP/UDP
Internal Port(s): 8022~8022
External Port(s): 8022~8022
Server IPv4: 192.168.0.45
Server IPv6: 2601:47:4980:15b0:0:0:0:b7ca 

Service Name: Jellyfin Server
Service Type: TCP
Internal Port(s): 8920~8920
External Port(s): 8920~8920
Server IPv4: 49.57.50.46

---

The Jellyfin Server configurations (automatically generated) work just fine, but for some reason use an IP address that's totally unfamiliar to me (49.57.50.46 - is that just how uPnP works?) whereas the actual static IP address for the ethernet connection, the one that I use to SSH into my RPI, doesn't work. I can't even use certbot without doing a DNS-01 challenge, which, to my understanding, doesn't require port 80 to be open. Also this was going on with ufw disabled, but even when I enable it and allow those ports, I still get this issue.

What is going on here? I am away from my home computer so I can provide more details later, but I spent hours the past couple of days trying to figure out why this was happening. 

Thank you.

[TheDreadPirate]

You should not use uPnP for port forwarding rules. You should set static rules. uPnP rules expire after a while on most routers.

UFW being disabled does not mean the firewall is disabled. UFW is a front end for iptables of nftables. When UFW is disabled, any rules created by UFW are disabled, but iptables/nftables is still running.

What MIGHT be happening is that your ISP is blocking ports 80 and 443. Some ISPs do not allow web servers on residential Internet plans. You would get around this by using a non-standard port to run the reverse proxy on and by using a DNS challenge for getting certs (which you've already done).

Change your reverse proxy to listen on a random port, preferably in the ephemeral range (49152–65535), setup port fowarding and UFW accordingly, and try again.

[telepathicChimp]

@TheDreadPirate, thank you for the reply.

I am at work right now, but I'll try out some of your suggestions when I get home.

You should not use uPnP for port forwarding rules. You should set static rules. uPnP rules expire after a while on most routers.

I see. It's strange because the uPnP rules are the only ones that work, but I'll try turning it off since, like I said, they create port forwarding rules to a completely unrecognizable IP.

UFW being disabled does not mean the firewall is disabled. UFW is a front end for iptables of nftables. When UFW is disabled, any rules created by UFW are disabled, but iptables/nftables is still running.

Thank you for this information. I guess I meant to say that I encounter this issue whether ufw is enabled or disabled, **or** if I have allowed HTTP/HTTPS. Explicitly allowing those ports still does not allow anything to come through. I'll try again when I get home, though.

Some ISPs do not allow web servers on residential Internet plans.

I already checked and Comcast explicitly does not block 443 or 80. However, I still believe this might be a possibility since I have experienced so much bitter frustration in trying to make this work.

Change your reverse proxy to listen on a random port, preferably in the ephemeral range (49152–65535), setup port fowarding and UFW accordingly, and try again.

This, I don't quite understand. The way I have it set up now, when I connect to https://jellyfin.example.com, my DNS provider points it to my remote VM, which is SSL-certified and running Nginx. The Nginx configuration forwards to port 8096 (default unencrypted to my pi). My pi's Nginx then forwards to https://example.jellyfin.com:8920, which is admittedly quite confusing and doesn't intuitively make sense to me or maybe anyone else, but that's how I was able to get it to work (I could be wrong so I'll go double-check when I get home). Both my pi and my remote VM are using the same certificates for https://example.jellyfin.com. Both 8096 and 8920 are automatically being forwarded on my router, set up by uPnP. I have also configured ufw to block any connections not originating from my remove VM or my LAN.

If I set up my reverse proxy to listen on a random port in the ephemeral range, wouldn't that make it not possible for friends or family to connect to it like a web page? I know you can select the desired port in the Jellyfin app but it would be cool to have the web page working as well. Or are you saying reverse proxy requests on 80 and 443 on my remote VM to 49152–65535 on my public IP? I am also new to this stuff so I appreciate your patience as I juggle these terms.

On an unrelated note, I'm probably going to sell the pi soon anyway since it's apparently not great, either for Jellyfin or for Steam Link.

[TheDreadPirate]

Ok. Going back a bit. When you say that the reverse proxy is on a remote machine, do you mean remote to Jellyfin? As in not on the same host? Or do you mean it is remote to your home?

You do NOT need to have port forwarding setup on the router for port 8096 if the reverse proxy is on your home network.

Internet -> Router (https port 443 port forwarding to reverse proxy) -> reverse proxy (https port 443, ufw rule for port 443) -> jellyfin server (http port 8096, ufw rule for 8096)

Also, what is this IP? 49.57.50.46. That doesn't look like a Comcast IP (I'm also on Comcast). Are you using a VPN?

[telepathicChimp]

   

I have attached a Mermaid flowchart to explain what I'm talking about. 

I have a DO server. Requests for a subdomain of my server are reverse proxied to my home router. Here is the configuration for that proxy:

Code:

server {
    listen 443 ssl http2;
    server_name example.jellyfin.com;
    ssl_certificate /etc/letsencrypt/live/example.jellyfin.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.jellyfin.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        proxy_pass https://5.6.7.8:8920;
        proxy_ssl_verify off;
        #proxy_ssl_trusted_certificate /etc/letsencrypt/live/example.jellyfin.com/fullchain.pem;
        #proxy_ssl_protocols TLSv1.2 TLSv1.3;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Connection "upgrade";
        proxy_set_header Upgrade $http_upgrade;
    }

}

# Redirect HTTP to HTTPS for example.jellyfin.com
server {
    if ($host = example.jellyfin.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    server_name example.jellyfin.com;
    return 301 https://$host$request_uri;


}

I have port-forwarding for port 8920 (I think I gave the wrong port in a previous post). Here is the Nginx configuration on my Raspberry Pi machine:

Code:

server {
    listen 80;
    server_name example.jellyfin.com;

    location / {
        return 301 https://example.jellyfin.com$request_uri;
    }
}


server {
    listen 443 ssl http2;
    server_name example.jellyfin.com;

    # Use your new Let’s Encrypt cert
    ssl_certificate /etc/letsencrypt/live/example.jellyfin.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.jellyfin.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    # Simple redirect to Jellyfin's built-in HTTPS port
    location / {
        return 301 https://example.jellyfin.com:8920$request_uri;
    }
}

So if you visit example.jellyfin.com, you get redirected to my home router at 5.6.7.8 at port 8920. If, for whatever reason, someone visits example.jellyfin.com on their web browser, they, too, get redirected to 8920. 

I have the following ufw rules in place:

Code:

❯ sudo ufw status
Status: active

To                        Action      From
--                        ------      ----
22/tcp                    ALLOW      Anywhere
8096/tcp                  ALLOW      1.2.3.4
8920/tcp                  ALLOW      1.2.3.4
8096/tcp                  ALLOW      192.168.0.0/24
8920/tcp                  ALLOW      192.168.0.0/24
8096/tcp                  DENY        Anywhere
8920/tcp                  DENY        Anywhere
443                        ALLOW      Anywhere
80/tcp                    ALLOW      Anywhere
22/tcp (v6)                ALLOW      Anywhere (v6)
8096/tcp (v6)              DENY        Anywhere (v6)
8920/tcp (v6)              DENY        Anywhere (v6)
443 (v6)                  ALLOW      Anywhere (v6)
80/tcp (v6)                ALLOW      Anywhere (v6)

Anyway, ports 80 and 443 are blocked for some reason. I can't figure out why. And it seems that Comcast isn't blocking those ports. 

The ip 49.57.50.46 was automatically set up by Jellyfin, presumably by uPnP. The actual LAN IP address for my ethernet-connected Pi, 192.168.0.45, doesn't work for my router's port-forwarding rules, even though that's the IP address I use to SSH into my Pi.

I hope I explained myself well, and I, once again, thank you for all your help.

[TheDreadPirate]

I'm a bit confused. Why is the RPi running a proxy at all? The DO Nginx proxy is going directly to Jellyfin via port 8920. It would never interact with the RPi proxy, as configured.

If your jellyfin subdomain, or the whole domain, points to the DO IP your RPi Nginx proxy never comes into play ever.

It isn't clear which host the UFW rules are from. But if they are from the server running Jellyfin, port 8920 is blocked. I'm assuming the UFW rules you've shown are from the RPi running Nginx. Regardless, on your home router port 8920 should be forwarding directly to Jellyfin and not the RPi. This is based on how you currently have things configured.

Users ---> 443<>DO Nginx<>8920 ---> 8290<>router<>8920 ---> 8920<>Jellyfin

If you do want the RPi to act as a second proxy, you'd need to change the DO proxy.

From

Code:

proxy_pass https://5.6.7.8:8920;

To

Code:

proxy_pass https://5.6.7.8;

THEN the RPi proxy is used. Ideally, you would switch to http at this point on port 8096 since the traffic is now on the LAN.

Users ---> 443<>DO Nginx<>443 ---> 443<>router<>443 ---> 443<>RPi Nginx<>8096 ---> 8096<>Jellyfin Server

Some Nginx comments. You need to have a /socket location since you are using http2. Websockets are http 1.1 only. You can skip having that separate /socket location if you include a http 1.1 downgrade in the / location.

If you go with the DO to Jellyfin 8920 setup, you'd need a /socket location on the DO proxy. If you bring in the RPi Nginx into the mix, I THINK you would need a /socket location in BOTH the DO Nginx and RPi Nginx.

Another option you can explore is to forego the RPi Nginx entirely and setup Wireguard between the DO server and the Jellyfin server. This keeps the DO to Jellyfin traffic encrypted without the need for a second HTTPS connection.

[telepathicChimp]

Hey! Thank you so much for all your help. I was away because I sold my RPis for an Intel N150 Beelink S13 Mini-PC, installed Ubuntu Desktop on it (I also wanted to set up Steam Link), then spent many hours figuring out why Ubuntu couldn't recognize the Alder Lake iGPU (turns out I just had to install either kernel version 6.11 or newer or just install Ubuntu 24.10 instead of 24.04... I feel the need to make a post somewhere about this because of the amount of time I invested in figuring it out, although I'm sure others have made similar posts elsewhere).

I simplified my setup by

- disabling https on my home server,
- removing Nginx configurations on my home server (since I don't technically need it... at least not yet, might want to enable remote ssh eventually for other reasons),
- only port-forwarding to 8096,
- disabling uPnP,
- having my DO server reroute to 8096 on my home server.

Now I'm looking into WireGuard to protect traffic between my DO server and my home IP address. If you have any tips or anything on that, I would greatly appreciate it!

[TheDreadPirate]

Nope. Just setup Wireguard as server on the DO server, Wireguard as a client on the home PC.

If you do go this route, you'd be able to disable the 8096 port forwarding on your router.

On the home PC running Wireguard as a client, I think you'd want the "AllowedIPs" setting in the wireguard config to only be the IP of your Wireguard server.

Something like this.

Code:

AllowedIPs = 10.0.0.1/32

Where 10.0.0.1 is the IP of the server's wireguard interface. This should allow you to use Wireguard for remote access for Jellyfin, but it won't force all your other traffic to also go through Wireguard.