tbyt2000 5 Posted June 3, 2019 Posted June 3, 2019 Hi. Not sure whether this is a feature request but I can't see where to turn it off anywhere. I have a local network in the 10.10.10.0/24 range. I want all clients on this network to be seen as LAN clients. To achieve this I add 10.10.10.0/24 to the Advanced -> LAN Networks dialogue box. So far so good. Emby (and my proxy server for external connections) are running in Docker containers on a logical 172.17.0.0/24 network. I can't use a transparent proxy for various boring reasons, so all external connections adopt the proxy server's IP address. This makes them look like they are on the same network as the Emby server (172.17.0.x). Emby then treats them all as on the local LAN - even though I only specified 10.10.10.0/24 as local. It seems to add the server network automatically. Can we have a feature to exclude the server network from the local client networks please? Thanks, tbyt2000
dotcom 8 Posted June 4, 2019 Posted June 4, 2019 If you set external as a dns address headers should pass through and be external. That’s how it works with my container setup. I use an nginx proxy and do ssl termination there.
tbyt2000 5 Posted June 4, 2019 Author Posted June 4, 2019 Thanks dotcom. I agree that *should* work (and I use nginx too), but before traffic hits nginx it hits another container running sslh so I can use SSH, SSL and OpenVPN all on port 443 (my work network blocks port 22 outbound so I have to SSH on port 443). This breaks transparent proxy so nginx only sees the 172 address of the sslh container and passes that through to Emby. As all connections look internal to nginx (and emby) I can't distinguish using DNS header. As containerisation increases it's going to be more and more common for servers to run on a separate network to clients so it would be a great to be able to remove the server network from the list of client networks.
dotcom 8 Posted June 4, 2019 Posted June 4, 2019 How about proxy_set_header? http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header
Luke 42079 Posted June 4, 2019 Posted June 4, 2019 Yea why not configure headers in the proxy so that Emby can see the original IP address? Currently we assume certain 172.X addresses to be private address space, so that's why they are treated as in-network. It's possible to consider revising this, but it could be potentially painful as we've had it this way for a long time and many users would undoubtedly be affected by changing it.
dotcom 8 Posted June 4, 2019 Posted June 4, 2019 (edited) Always best to configure proxies appropriately and let the software do its thing. Edited June 4, 2019 by dotcom
tbyt2000 5 Posted June 5, 2019 Author Posted June 5, 2019 Thanks for the replies. I agree with you both. unfortunately I have to use port 443 for multiple protocols (due to restrictions at work). I have SSH, SSL and OpenVPN all coming in on port 443 and sslh is required to split and route the different protocols to the appropriate services. This limits the ability of the proxy server to work as it should as it doesn't see the original header. Maybe I've configured it wrong but lots of other people on the Internet have the same problem with sslh and I can't find a fix. I can see why you assume 172 to be local but, in a modern network it's wrong to always assume 'local' and 'client network' are the same - my clients don't sit on my server network. I don't think fixing it would have a huge impact - people would just have to add their client network to the list of LAN networks (which is expected behaviour) and you could even add it for them as a one-time upgrade step. I get though that I'm an edge-case at the moment. I'll disable password bypass on my users and put passwords into all my LAN connected clients. Not the end of the world. Hopefully one day we'll get the network exclusion option in Emby, or a fix in sslh. I know you have lots of other priorities to fix and improve - and I get to enjoy the benefits of all these too Keep up the great work - you have a truly awesome product here. tbyt2000
Q-Droid 989 Posted June 5, 2019 Posted June 5, 2019 (edited) Isn't this what you want? It's straight from the sslh GitHub page: Transparent proxy support On Linux and FreeBSD you can use the --transparent option to request transparent proxying. This means services behind sslh (Apache, sshd and so on) will see the external IP and ports as if the external world connected directly to them. This simplifies IP-based access control (or makes it possible at all). Edited June 5, 2019 by Q-Droid
tbyt2000 5 Posted June 5, 2019 Author Posted June 5, 2019 Hi Q-Droid. Yes it is. Unfortunately it doesn't work - especially from a Docker container (I tried a native install too though). I lost a day-and-a-half scouring every forum. Tried a lot of different suggestions before finally going off in a huff. I'm not so bothered about source IP addresses as I have a small Emby community. The main thing I was after was separating local machines from remote (so I don't need passwords internally). I think I'll look at creating a new, separate, docker virtual network and putting the Emby container on it (on it's own). Should solve my problem. Thanks for the suggestion though
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now