Issue disabling remote connection for a given user - Printable Version +- Jellyfin Forum (https://forum.jellyfin.org) +-- Forum: Support (https://forum.jellyfin.org/f-support) +--- Forum: General Questions (https://forum.jellyfin.org/f-general-questions) +--- Thread: Issue disabling remote connection for a given user (/t-issue-disabling-remote-connection-for-a-given-user) |
Issue disabling remote connection for a given user - segovid - 2025-01-19 I am currently using Jellyfin server 10.9.11 in a Synology DS918+ docker. I had initially set-up 2 users: - an admin user with no remote connection enabled - a regular user, with no password, that uses the libraries on my local network only (it's my go-to viewer account that has all my favorites and on-progress status) I want to set-up the following 3-users org: 1- admin user with no remote connections, as before 2- regular user with no no remote connections, no password, and no ability to change the server settings, as before (my viewing account) 3- a remote user for a family member, with remote connection enabled, and no ability to change the server settings. So I have set-up a reverse proxy with let's encrypt certificate and everything works fine except for one thing: user number1 , the admin, and user number 2, my own viewing account, are still able to connect remotely, even though I disabled their ability to connect remotely in their respective user settings. I tried to stop and restart docker but I just can't prevent these users to connect remotely... I thought that perhaps it was related to chrome retaining some settings so I tried with Edge as well and I got the same issue. With the admin account, I enabled remote connections in the networking settings. Then for the admin and regular user, I disabled remote connections in the user settings, and I enabled remote connections for the remote user in its own user setting. Don't know what else to do... What am I doing wrong ? Is this a bug ? RE: Issue disabling remote connection for a given user - TheDreadPirate - 2025-01-19 Is the proxy running on a separate machine? Or in a container? You'd need to add the proxy's IP to the Known Proxies setting so that Jellyfin will know to read the x-forwarded-for header, which contains the real client IP. RE: Issue disabling remote connection for a given user - segovid - 2025-01-20 Thank you for your quick response ! The reverse proxy was setup using Synology reverse proxy feature so it is running on the same machine, but AFAIK not in a container. I added these lines in the custom header section: Upgrade $http_upgrade Connection $connection_upgrade X-Real-IP $remote_addr X-Forwarded-For $proxy_add_x_forwarded_for X-Forwarded-Proto $scheme X-Forwarded-Protocol $scheme X-Forwarded-Host $http_host Host host In the Jellyfin server Known Proxies setting, I added: 127.0.0.1, 192.168.0.9, 192.168.0.1, mydomain.com, jellyfin.mydomain.com where 192.168.0.9 is my synology IP address (that runs the jellyfin docker and the reverse proxy), and 192.168.0.1 is my gateway IP address. I also added 192.168.0.0/24 192.168.0.1 192.168.0.9 to Synology's trusted proxies list Now when I connect from the reverse proxy address jellyfin.mydomain.com, any user still manages to connect and the Jellyfin log indicates connections from 192.168.0.1 (the gateway) for any user. The gateway is using DD-WRT. I just forward the port 443 to 192.168.0.9. and I am not forwarding the port 80. Could that be the gateway removing the public IP address ? RE: Issue disabling remote connection for a given user - segovid - 2025-01-20 (forgot to add) And I turned the jellyfin docker off and on every time I changed a network setting. RE: Issue disabling remote connection for a given user - TheDreadPirate - 2025-01-20 Remove the domain names from the known proxies. You should only use IPs or hostnames. As in the local DNS name of the PC. Also remove the CIDR, 192.168.0.0/24. It should only be specific IPs. So it should only contain "192.168.0.1,192.168.0.9". Ensure each IP is comma separated. The reason your router is showing up as a proxy is probably due to NAT loopback/hairpin. |