How to prevent apps from discovering/preferring "local"/LAN IP of server.

[Napsterbater 38]

Previously I have always connected the apps to the server with a hostname, that hostname has always resolved via normal DNS and resolved to my reverse proxy, or now a cloudflard tunnel. Either way If necessary, I controlled where that domain name resolved in this how the app on a client should access the Emby server.

Something has recently changed where the apps (maybe just Andriod app), Even when initially connected by typing in the host name, are discovering and then attempting and preferring to use the Emby server self discovered Local/LAN non HTTPs IPv4 of the Emby server, Not the IPv6 and HTTPs I intend them to connect to.

On the server I have the "Local IP address" set with the host name, which again even on that server would resolve not to the actual (real) host IP but seems though the emby server ignores it (This has pretty much always been set but might not have actually mattered before), Not only that, it uses and Legacy IP and not IPv6, Even for clients that are single stacked IPv6, which forces them to go through CLAT/NAT64

Is there any way to prevent this? If I wanted to use the local IP, I would have done it, I'm specifically using a hostname for a reason.

 

[GrimReaper 5055]

3 hours ago, Napsterbater said:

Is there any way to prevent this?

Block UDP port 7359 (used for automatic local network discovery/server announcement) in your firewall. 

[Napsterbater 38]

Did that, doesn't change anything.

And based on how far back that suggestion goes, doesn't seem to be related to the recent change.

[Clackdor 114]

1 hour ago, GrimReaper said:

Block UDP port 7359 (used for automatic local network discovery/server announcement) in your firewall

 

59 minutes ago, Napsterbater said:

Did that, doesn't change anything.

And based on how far back that suggestion goes, doesn't seem to be related to the recent change.

Blocking 7359 solves the problem for the first time connection as the server isn't being advertised. The problem is that the server will still publish the internal IP and http port to clients once they have been connected and signed in. Clients that are aware of both the internal and external url of the server seem to prefer the internal url when on the internal network.  Also blocking 8096 on the server's Firewall is the only way to force clients to not auto switch to the server's internal IP:8096 as it will fallback to the external domain. The problem with doing this is that this also breaks DLNA only devices or reverse proxies not on the same machine that emby is running on that need that http only connection. Blocking connections at server's OS firewall level may also either be extremely convoluted or not possible in some setups. I use Windows, so it's fairly trivial there, but doing so in certain deployment types like docker with host networking, macvlan, etc may not be even be possible.

The real solution is to just have an officially supported option to have the emby server advertise a URL for internal connections rather than just advertising the IP and the server's internal http port. Ideally a separate internal domain field similar to what we have for specifying the external domain along with specifying the protocol and port. It could just advertise the external domain as a simpler solution, but having the additional options would be nice for those that have different internal/external access urls and more elaborate reverse proxy configs. This would completely solve the problem for app clients that switch between the external and internal URL's to have https everywhere while not breaking other functionality or setups that still need the http connection directly to the emby server.  Devs may want to add a fallback to just the server's IP and http port in case of DNS resolution issues, but I would assume that anyone wanting to force clients to use https connections locally with a domain name should know that they will need local DNS records for everything to work anyways.

Edited 3 hours ago by Clackdor

[yocker 1739]

"NAT Hairpinning" is probably what you are looking for. If i understand want you want correctly.
It's something that needs to be enabled in the router.

Edited 2 hours ago by yocker

[Clackdor 114]

7 minutes ago, yocker said:

"NAT Hairpinning" is probably what you are looking for. If i understand want you want correctly.
It's something that needs to be enabled in the router.

Not really the issue here. The problem is that the server will still publish it's own local IP and http port to certain clients even if they are connected using a domain name. If the client is on the local network it will prefer to use the local IP of the server and it's http port if they are available and not blocked by a firewall. I know for a fact this happens on android, and i believe the windows and xbox apps as well, possibly others too. The Roku app is the only one that I'm aware of that doesn't seem to switch to the server's IP address and http port if you use a domain name when first connecting when you're on a local network.

This is easily verifiable by checking emby server as well as reverse proxy logs if you're using one. If you manually enter the domain name, the app will connect through the reverse proxy using the domain name. As soon as you close and re-open the app it will connect straight to the server's IP and HTTP port unless blocked. This happens even if you block the server's discovery port (UDP 7359) or even if the client and server are on separate VLAN's where the UDP discovery service doesn't even come into play. So there's 2 things that would need to be addressed. The server needs to be able to advertise a domain on the UDP 7359 discovery service for first time connections as well as advertise a domain URL locally to clients that have the ability to switch between internal/external URL's based on whether or not they are in a local network.

[yocker 1739]

1 hour ago, Clackdor said:

Not really the issue here. The problem is that the server will still publish it's own local IP and http port to certain clients even if they are connected using a domain name. If the client is on the local network it will prefer to use the local IP of the server and it's http port if they are available and not blocked by a firewall. I know for a fact this happens on android, and i believe the windows and xbox apps as well, possibly others too. The Roku app is the only one that I'm aware of that doesn't seem to switch to the server's IP address and http port if you use a domain name when first connecting when you're on a local network.

This is easily verifiable by checking emby server as well as reverse proxy logs if you're using one. If you manually enter the domain name, the app will connect through the reverse proxy using the domain name. As soon as you close and re-open the app it will connect straight to the server's IP and HTTP port unless blocked. This happens even if you block the server's discovery port (UDP 7359) or even if the client and server are on separate VLAN's where the UDP discovery service doesn't even come into play. So there's 2 things that would need to be addressed. The server needs to be able to advertise a domain on the UDP 7359 discovery service for first time connections as well as advertise a domain URL locally to clients that have the ability to switch between internal/external URL's based on whether or not they are in a local network.

Out of curiosity may i ask why you want it to loop through the internet instead of just using local address?