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.