Jump to content

LAN networks - exclude server network


Recommended Posts

tbyt2000
Posted

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

Posted

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
Posted

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.

Posted

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.

Posted (edited)

Always best to configure proxies appropriately and let the software do its thing.

Edited by dotcom
tbyt2000
Posted

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
Posted (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 by Q-Droid
tbyt2000
Posted

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 :)

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...