Jump to content

Secure Connection Failed on some networks


Recommended Posts

EmilioGarcia
Posted

Not sure where the issue is on this one. Connecting to my emby server over https results in "Secure Connection Failed" errors on some remote subnets, but works fine on others.

When I attempt to connect via the problematic subnets, I see

Secure Connection Failed

An error occurred during a connection to emby_remote_IP:54813. PR_CONNECT_RESET_ERROR

Error code: PR_CONNECT_RESET_ERROR

In the emby server logs, each failed connection request generates the following log entries:

2024-12-09 23:51:09.195 Info Server: http/1.1 Response 404 to 127.0.0.1. Time: 0ms. GET https://emby_remote_ip:54813/embywebsocket?api_key=x_secret2_x&deviceId=140ae1ca-96db-462f-bd2c-5989d15cf03a
2024-12-09 23:51:10.234 Info Server: http/1.1 POST https://emby_remote_ip:54813/emby/Sessions/Capabilities/Full?X-Emby-Client=Emby Web&X-Emby-Device-Name=Firefox macOS&X-Emby-Device-Id=140ae1ca-96db-462f-bd2c-5989d15cf03a&X-Emby-Client-Version=4.8.10.0&X-Emby-Token=x_secret2_x&X-Emby-Language=en-us&reqformat=json. Source Ip: 127.0.0.1, UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:133.0) Gecko/20100101 Firefox/133.0
2024-12-09 23:51:10.234 Info Server: http/1.1 Response 204 to 127.0.0.1. Time: 1ms. POST https://emby_remote_ip:54813/emby/Sessions/Capabilities/Full?X-Emby-Client=Emby Web&X-Emby-Device-Name=Firefox macOS&X-Emby-Device-Id=140ae1ca-96db-462f-bd2c-5989d15cf03a&X-Emby-Client-Version=4.8.10.0&X-Emby-Token=x_secret2_x&X-Emby-Language=en-us&reqformat=json
2024-12-09 23:51:10.240 Info Server: http/1.1 Response 404 to 127.0.0.1. Time: 0ms. GET https://emby_remote_ip:54813/embywebsocket?api_key=x_secret2_x&deviceId=140ae1ca-96db-462f-bd2c-5989d15cf03a

Otherwise, I don't really see any certificate errors.

Emby worked fine just recently over these same subnets. I do see that Port Mapper was recently updated — maybe something to do with it?

image.png.82b5a7e5bfc4599095b97f4350fcf492.png

embyserver.txt

Posted

The server log posted starts 5 minutes after the lines you show above.

These are the IPs Emby is listening on:
2024-12-09 23:56:33.404 Info App: Init BeginReceive on 0.0.0.0
2024-12-09 23:56:33.404 Info App: Init BeginReceive on 192.168.1.12
2024-12-09 23:56:33.404 Info App: Init BeginReceive on 127.0.0.1

It looks like you have 4 1Gb Ethernet adapters bonded together.

If you can restart the Emby server, wait 2 to let if fully load then try creating the issue again.
Upload the server log.

EmilioGarcia
Posted

I restarted the server to grab fresh logs, the lines I shared were just examples of the issue.

I've restarted the server, waited about 10 minutes, and then reproduced the issue — new logs are attached.

embyserver.txt

Happy2Play
Posted

Not sure where port 54813 comes from but Emby is listening on

2024-12-10 03:32:41.716 Info App: Adding HttpListener prefix http://+:8096/
2024-12-10 03:32:41.716 Info App: Adding HttpListener prefix https://+:8920/

 

Posted
5 hours ago, Happy2Play said:

Not sure where port 54813 comes from but Emby is listening on

2024-12-10 03:32:41.716 Info App: Adding HttpListener prefix http://+:8096/
2024-12-10 03:32:41.716 Info App: Adding HttpListener prefix https://+:8920/

 

He must have configured that as his router port for https.

So @EmilioGarciadid you setup port forwarding in your router from 54813 to 8920 ?

EmilioGarcia
Posted

This is a part I'm a bit confused about. I've set the public https port to be 54813:
image.thumb.png.a4208677e3bdae9c2c3cfb915fdf8bb8.png

But I see in the first screenshot that I shared, that the service is running on 8920, despite the URL being updated to 54813. Restarting Emby results in the same thing, it never stops running on 8920. My router is set to forward 54813 to 54813, and I have no port forwarding rules for http. There's no additional port forwarding in DSM, and UPnP is disabled on my router.

image.png.ed5bd7f614dcb3612a0cb8a8ebd76296.png

 

Happy2Play
Posted
12 minutes ago, EmilioGarcia said:

This is a part I'm a bit confused about. I've set the public https port to be 54813:
image.thumb.png.a4208677e3bdae9c2c3cfb915fdf8bb8.png

But I see in the first screenshot that I shared, that the service is running on 8920, despite the URL being updated to 54813. Restarting Emby results in the same thing, it never stops running on 8920. My router is set to forward 54813 to 54813, and I have no port forwarding rules for http. There's no additional port forwarding in DSM, and UPnP is disabled on my router.

image.png.ed5bd7f614dcb3612a0cb8a8ebd76296.png

 

Because there are to sections to change, Public and Local.

image.png.17187b489ee97c0113b93dc9a2030036.png

image.png.6b5b8d2fe144cf14ef1a83c32b0284f7.png

EmilioGarcia
Posted

It looks like that section is unavailable for the Synology package, per this thread (assuming it's still relevant, but I don't see that section currently, so it seems right):

Nonetheless, I can access the server through 54813, on some remote subnets, with my current port forwarding rules.

image.thumb.png.0a8f0780980fa955a8cd987c6da9fae9.png

However, I continue to receive the PR_CONNECT_RESET_ERROR on other remote subnets.

Posted

So were you able to forward 54813 to 8920 ?

EmilioGarcia
Posted

Somehow it seems to be forwarding, but I'm not sure how.

I only have 54813 -> 54813 forwarded on my router.

I have no ports forwarded in DSM:
image.thumb.png.86fccf7d7539bb1eec192864e2979f63.png

Since I'm seeing inconsistent access success, maybe somehow it's a DNS caching issue? I've restarted my Synology server several times, and I've tested access with fresh machines that wouldn't have anything for this site cached. I recently disabled UPnP on my router, but it doesn't look like there are any lingering rules.

Posted

Yes that is odd that it appears to be forwarding. upnp is the only thing I can think of it you haven't setup port forwarding for it.

Posted
On 12/10/2024 at 6:03 PM, EmilioGarcia said:

I only have 54813 -> 54813 forwarded on my router.

Since I'm seeing inconsistent access success, maybe somehow it's a DNS caching issue? I've restarted my Synology server several times, and I've tested access with fresh machines that wouldn't have anything for this site cached. I recently disabled UPnP on my router, but it doesn't look like there are any lingering rules.

If you turned off UPnP on your router, turn off Emby's automatic port mapping in Network options. 
Unless you have a reason to change the public port used by Emby server, switch it back to 8920 in Network option.
Login to your router and either edit the current 54813 -> 54813 port forward or delete it and create a new:
8920 -> 8920 port forward rule pointed to 192.168.1.12 (Emby's IP address).

----------------
With the settings you have now (going by pics) doing what Luke said would work as well.
54813 to 8920.  This simply means we listen on the WAN interface for activity on port 54813 and forward it on the LAN side to port 8920 destined for 192.168.1.12 (Emby IP).

----------------
Emby's network options have 2 sets of IP setups. One is for local and one set for public.
As a simplified explanation of these two sets of ports think of it this way.
Local Ports are what Emby BINDS to when starting the server.  These are the two ports Emby Server will listen on for general client connections and requests.  All traffic (Internet and LAN) all use these two ports.

Public Ports - Emby marks outgoing packets to non-Local traffic as coming from this port.  It doesn't use these ports directly as it's listening on the local ports.  For internet-based traffic Emby Server would be listening on 8920 (encrypted) port but marking it with the public port settings (may or may not be 8920).

If the local encrypted port is 8920 and the public encryption port was set to 9999 then Emby Server binds to 8929 which it listens for communication and requests on. It marks any outgoing packets with 9999 when responding. 
===
Advanced topic beyond this thread, but nice to understand why it's neat to have the ability to listen on different ports.  You may want all traffic using common ports such as port 80 and 443. Let's suppose you registered the domain "webhome.xyz".  On the NAS you install:
Emby with public unencrypted port set to 80 and public secured port to 443.
Joomla on port 6000
calendar on 6100
wordpress blog on 6200
DSM on 5100 (already setup)
You install a reverse proxy or use the Synology Applications prograam

You add A or C records to your domain all pointing to your WAN address for emby, web, cal, blog & dsm.

Your reverse proxy is configured to use a wildcard cert for your webhome.xyz domain.
You setup rules to:
forward all non matches to www.google.com
redirect all port 80 traffic to 443 (encrypted)
emby.webhome.xyz forwarded to port 8920
web.webhome.xyz to port 6000
cal.webhome.xyz to port 6100
blog.webhome.xyz to port 6200
dsm.webhome.xyz to port 5001
You can now use https for all your apps and access them by name with an easy to remember name like emby.webhome.xyz.
Synology has many apps that can be installed and setup this one such as mail.webhome.xyz, photos.webhome.xyz, office.webhome.xyz, etc

Hope that helps with some creative ideas, but most importantly with the correct use of Emby port numbers and the port forwarding you would setup on your router.
Remember to test your port forwarding using a website such as cnyousee me which can test to see if a port on your router is open or not.

Carlo

EmilioGarcia
Posted

Thanks @Carloand everyone else for the troubleshooting help.

I discovered that opening port 443 on my router allows the connection to go through successfully, with port forwarding rule 443 -> 8920. I now suspect that our firewall is blocking specifically https over non-443 ports on certain subnets, breaking the connection. It would explain why otherwise, public connections are fine, but certain subnets cause trouble. It would also explain why I'm able to netcat those ports and see them as open normally, but not be able to connect over https in the web browser. I think the reverse proxy approach is best, since I assume the network team where I work is not keen on making new rules for personal servers.

Thanks again, this should be resolved now, at least as far as Emby goes.

  • Thanks 2

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...