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

[Napsterbater 39]

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 39]

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 118]

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 9 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 9 hours ago by yocker

[Clackdor 118]

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?

[Clackdor 118]

34 minutes ago, yocker said:

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

With a LAN DNS server (or public dns records that point to internal IP's) there is no looping through the internet, nor is NAT reflection needed. The local DNS server will just resolve the domain name to an internal IP address (whether that's IPv4 or IPv6) I'm not the OP, so I can't speak for their particular setup. I can say with 100% certainty though that in my own setup that my domain name resolves to an internal ip address via local dns (my reverse proxy). Certain clients bypass that altogether and just communicate with the emby server on http port 8096 via it's advertised local IP rather than using https through the reverse proxy with the configured domain name.

Having client apps always use a domain name or always using https connections even locally has been asked for a long time. The only current way to accomplish this is with firewall rules on the server that can break functionality or may not even be possible to configure in the first place depending on the environment. The emby server needs options to advertise a domain name internally via the server discovery service and advertise a domain name as the internal address to clients that use it in order to accomplish this.

[yocker 1739]

34 minutes ago, Clackdor said:

With a LAN DNS server (or public dns records that point to internal IP's) there is no looping through the internet, nor is NAT reflection needed. The local DNS server will just resolve the domain name to an internal IP address (whether that's IPv4 or IPv6) I'm not the OP, so I can't speak for their particular setup. I can say with 100% certainty though that in my own setup that my domain name resolves to an internal ip address via local dns (my reverse proxy). Certain clients bypass that altogether and just communicate with the emby server on http port 8096 via it's advertised local IP rather than using https through the reverse proxy with the configured domain name.

Having client apps always use a domain name or always using https connections even locally has been asked for a long time. The only current way to accomplish this is with firewall rules on the server that can break functionality or may not even be possible to configure in the first place depending on the environment. The emby server needs options to advertise a domain name internally via the server discovery service and advertise a domain name as the internal address to clients that use it in order to accomplish this.

Isn't that precisely what NAT hairpinning is for? So you can do precisely that without the extra steps of having to run local DNS servers and such.

I'm in no way a network expert or even close to it so if i'm wrong please correct me.  

[Clackdor 118]

5 minutes ago, yocker said:

Isn't that precisely what NAT hairpinning is for? So you can do precisely that without the extra steps of having to run local DNS servers and such

NAT hairpinning/reflection has it's own set of issues and may not be properly supported by some routers or work in certain situations. Local DNS is overall cleaner IMO if you're trying to connect to local services using a domain name in most situations. Plus there may be other services that you want to access internally via domain, but not expose publicly, so an internal DNS is far better there. Either option is valid depending on how you want to configure things and what you have to work with etc.

Which one you choose doesn't necessarily matter in the context of the issue being discussed here though. Some Emby clients will just use the server's local IP and plaintext http port rather than the domain name over https if they are on the server's local network.

[Lessaj 528]

The only solution I've found to force traffic through my reverse proxy is to block the HTTP port - either via ACL on a switch, or directly on the server's firewall. If it can't connect on the local address it switches to the remote address, which resolves differently internally + externally depending on what network I'm on.

[Luke 42755]

There is no recent change, it's just always been this way. The apps will initially connect based on the manually entered address, but then they'll get updated values based on the addresses displayed on your server dashboard.

[TMCsw 283]

@Napsterbatersomething has changed on your end as emby has always done this.

[Napsterbater 39]

2 hours ago, Luke said:

There is no recent change, it's just always been this way. The apps will initially connect based on the manually entered address, but then they'll get updated values based on the addresses displayed on your server dashboard.

Something has absolutely has had to change, because up until the past month or so my apps never connected to the local IP.

Because the IP reported by the Emby server itself in current streaming sessions shows this has to be the case. And no it's not due to X-Forwaded headers or anything, because that wouldn't match it either.

They always utilized the IP associated with the DNS FQDN that I initially input to connect them with. And now they don't. They ignore it. They use the local IP and they're using HTTP vs HTTPs.

I've had to resort to blocking via local Firewall So clients cannot access the server directly, and only the reverse proxy and or cloudflare tunnel apps can.

That's never had to happen before. And Emby Network settings haven't changed for a couple years at this point. 

And this also happened on multiple Android apps, across a fire stick, Onn Google TV stock, And Android phone. Two different networks.

One network is actually in a completely different subnet across the VPN tunnel, so it couldn't even have seen the local broadcast Discovery mechanism that's in place either 

 

 

Edit: Also as I noted, The local IP address I've always had configured on the network settings page in Emby, it was this FQDN, not an IP.

And again that FQDN does not resolve to the local IP/s of the Emby Server.

Edited 52 minutes ago by Napsterbater