User IP Address when going through Cloudflare

[BAlGaInTl 279]

Hello all...

Last week, I was investigating some unusual behavior on my server.  I wanted to take a look at some IP addresses when I realized that since I run everything through Cloudflare, Emby reports the Cloudflare IP address to me.

Is there any way to capture record the actual User IP address instead?

It's my understanding that the original IP address is available in the header information from Cloudflare.  I don't know if anybody has experimented with this before.

Of course it may be complicated since I'm also running in Docker and through a reverse proxy.

Just curious if anybody has an easy solution.

[Luke 37009]

HI, yes you'll have to configure the proxy to pass the values though. @pir8radio may have some tips.

[pir8radio 1292]

On 5/3/2021 at 9:57 AM, BAlGaInTl said:

Hello all...

Last week, I was investigating some unusual behavior on my server.  I wanted to take a look at some IP addresses when I realized that since I run everything through Cloudflare, Emby reports the Cloudflare IP address to me.

Is there any way to capture record the actual User IP address instead?

It's my understanding that the original IP address is available in the header information from Cloudflare.  I don't know if anybody has experimented with this before.

Of course it may be complicated since I'm also running in Docker and through a reverse proxy.

Just curious if anybody has an easy solution.

 

On 5/3/2021 at 12:52 PM, Luke said:

HI, yes you'll have to configure the proxy to pass the values though. @pir8radio may have some tips.

Yea emby "USED" to abide by the "forwarded for" header..    Something changed a while back, where emby no longer displays the proxy hops and end user IP correctly..  Emby seems to ignore the "X-Forwarded-For" header, or only displays one ip from that header. 

The only work around is if you use nginx as a local reverse proxy as well.   and then you use the  "http_CF_Connecting_IP" header as a fix.  

 

That said @Luke any chance on getting this fixed?   Here is an example.     The first image is what emby "sees" or shows for a user connecting to emby.  in my setup EVERYTHING goes through a proxy so I should ALWAYS see two addresses for every connecting user. 

The only reason the below image has the real ip of the user is because I am forcing it using nginx, otherwise it would display 127.0.0.1 because my local proxy is connecting to emby.     PLEASE SWITCH BACK TO USING X-FORWARDED-FOR first ip in the string as the user IP.    Real-IP only gives emby the last known ip to connect to emby which is totally wrong. 

Yet if you look in the emby logs it shows the proper chain of forwarded for IP's but emby us using something else. 

2021-05-04 02:46:56.470 Info Server: http/1.1 GET http://removed.com/emby/videos/11187405/hls1/main/14.ts?DeviceId=REMOVED-9bac-aa0be8f56db3&MediaSourceId=REMOVED66490e27ef9a010181ac4&PlaySessionId=8REMOVED59ce2b823a4ab&VideoCodec=h264,mpeg2video&AudioCodec=ac3,aac,mp2,mp3,eac3,flac,vorbis,lpcm&VideoBitrate=3616001&AudioBitrate=384000&MaxFramerate=60&MaxWidth=3840&MaxHeight=2160&AudioStreamIndex=1&TranscodingMaxAudioChannels=6&SegmentContainer=ts&SegmentLength=3&MinSegments=1&BreakOnNonKeyFrames=True&ManifestSubtitles=vtt&h264-maxrefframes=16&h264-videobitdepth=8&h264-profile=high,main,baseline,constrainedbaseline&h264-level=51&aac-audiochannels=6&eac3-audiochannels=6&ac3-audiochannels=6&flac-audiochannels=6&lpcm-audiochannels=6&mp3-audiochannels=2&mp2-audiochannels=2&vorbis-audiochannels=6&TranscodeReasons=ContainerBitrateExceedsLimit. Connection=Keep-Alive, Accept=*/*, Accept-Encoding=gzip, Host=removed.com, User-Agent=Roku/DVP-9.40 (559.40E04210A), X-Real-IP=69.47.146.93, X-Forwarded-For=69.47.146.93, 108.162.216.48, CF-RAY=64a01e3ea8b48516-ORD, X-Forwarded-Proto=https, CF-Visitor={"scheme":"https"}, CF-Connecting-IP=69.47.146.93, CDN-Loop=cloudflare, cf-request-id=09d7f13b2c00008516d01b1000000001

X-Forwarded-For=69.47.146.93, 108.162.216.48,      is what emby should abide by, and the first ip in that list should always be the user IP.   everything else in that string will be the servers that user passed through.   in my case cloudflare.       Those without nginx, you are some how picking up the connecting ip which will be the proxy or forwarding server..    I'm not sure how you are getting the ip but you are getting the wrong one in proxy configurations. 

After looking a bit, it looks like emby is looking at X-Real-IP  which is NOT actually the real ip...   its the connecting IP not the client ip. 

 

 

Here is an example of what emby does when I do not overwrite the X-Real-IP  It shows my local server proxy ip.   and I'm logged in from a remote internet connection here...

Edited May 5, 2021 by pir8radio

[Spaceboy 2493]

Yep please fix this Luke 

[Luke 37009]

X-forwarded-for is still supported.

[pir8radio 1292]

51 minutes ago, Luke said:

X-forwarded-for is still supported.

maybe, but it looks like emby is not using it..   I tried to blank out X-Real-IP and emby just picks the last connecting IP of my local nginx 127.0.0.1     and emby NEVER shows the comma separated list of IP's in the dashboard any longer.    I'm not sure the logic flow of how emby picks the user IP....   X-Forwarded-For should be the highest priority for selecting the user IP, then fall back to other methods.  IMO

Edited May 5, 2021 by pir8radio

[pir8radio 1292]

3 hours ago, Luke said:

X-forwarded-for is still supported.

"X-Real-IP is the IP address of the actual client the server is talking to (the "real" client of the server), which, in the case of a proxied connection, is the proxy server."

Is the definition i found for x-real-ip, which is why we are all seeing the wrong ip in emby..    This could read wrong in emby for proxies, CDN's, cache servers that some isp's and companies use.  It opens the doors for you to get the wrong ip in many different scenarios.  Which is why grabbing the left most value from X-Forwarded-for is the correct method..

 

For example:     CLIENT-----------Cloudflare----------Proxy----------Cache Server----------EMBY       x-forwarded for would look like: CLIENTIP, CF-IP, PROXY IP, CACHE SERVER IP and emby would just use the client IP in that string. 

However the way you have it today using X-Real-IP you only get the ip of the device right outside of emby, in the above example emby would use CACHE SERVER IP which is not the client, that IP could be local to a lan, causing emby to use the LAN transcoding rules,  or auto login local users...     again incorrect IMO. 

[Luke 37009]

We support both, but we're checking the last value in both, and for x-forwarded-for it needs to be the first value. Thanks.

[Carlo 4330]

It would be good to take a look at the order being used Luke as it's picking up the wrong IP.  If x-forwarded-for is set then the first entry is what you would log (or the whole string).

[ebr 14903]

2 hours ago, cayars said:

It would be good to take a look at the order being used Luke as it's picking up the wrong IP.  If x-forwarded-for is set then the first entry is what you would log (or the whole string).

I think he just indicated that we're currently looking at the wrong end in that case .

[pir8radio 1292]

3 hours ago, Luke said:

We support both, but we're checking the last value in both, and for x-forwarded-for it needs to be the first value. Thanks.

 

59 minutes ago, ebr said:

I think he just indicated that we're currently looking at the wrong end in that case .

That is correct.    https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For

 

[BAlGaInTl 279]

I would love to get this fixed... even though I don't use it that often.

I'm on an edge case with Cloudflare going through a local proxy.  I know not everybody is set up that way.

[pir8radio 1292]

53 minutes ago, BAlGaInTl said:

I would love to get this fixed... even though I don't use it that often.

I'm on an edge case with Cloudflare going through a local proxy.  I know not everybody is set up that way.

I am.   if you mean       User------CF-------PROXY--EmbyServer

I use the same setup.

[Spaceboy 2493]

same here

[Luke 37009]

Yes we'll get that resolved. Thanks for the feedback.

[pir8radio 1292]

On 5/6/2021 at 9:33 AM, Luke said:

Yes we'll get that resolved. Thanks for the feedback.

did this get fixed in any of the recent betas?   Up to 4.6.0.46 now.

[Luke 37009]

X-forwarded-for was changed to look at the first ip address when multiple are supplied.

[pir8radio 1292]

12 hours ago, Luke said:

X-forwarded-for was changed to look at the first ip address when multiple are supplied.

oh this is good news I can remove my band-aid and test thank you!

[pir8radio 1292]

13 hours ago, Luke said:

X-forwarded-for was changed to look at the first ip address when multiple are supplied.

I have confirmed this appears to be working as expected.   It looks like you also prioritize the X-forwarded-for IP over x-real-ip   which is also good IMO.   

I tested by passing the default headers to emby with no modification.    Emby reported proper client IPv6 and IPv4 IP's.

I then had my reverse proxy force x-real-ip to 1.1.1.1   and tested again, emby reported the correct IPv6 and IPv4 addresses (not the fake 1.1.1.1). This test seems to confirm that emby is preferring the x-forwarded-for over x-real-ip  which is a very good thing again IMO.   

 

Thanks for taking the time to look into this small item.    Its a big deal to some of us with proxies or other devices between the client and the server, especially if emby believes the remote client is actually on the LAN and not connecting remotely.   

Edited May 16, 2021 by pir8radio

[Luke 37009]

Thanks for the feedback.

[niallobr 9]

@pir8radio I have a reverse proxy tunnel between my Synology NAS and VPS to bypass CGNAT. My domain is hosted on Cloudflare but I'm not sending traffic through their CDN. Any remote users that connect are being seen as 127.0.0.1 in Emby so my remote bandwidth limit isn't being enforced.

Do you think this is because my reverse proxy headers are simply wrong or is something else like the issue you described affecting me? I'm on Emby server 4.6.0.52 beta.

 

 

I can connect using the Emby app or browser remotely using the domain without any problems, it's just I'm being seen as a local user whenever I connect.

 

I've been wracking my brain trying to fix it so any help would be really appreciated!

Edited May 27, 2021 by niallobr

[Luke 37009]

4 minutes ago, niallobr said:

@pir8radio I have a reverse proxy tunnel between my Synology NAS and VPS to bypass CGNAT. My domain is hosted on Cloudflare but I'm not sending traffic through their CDN. I'm on Emby server 4.6.0.52 beta but any remote users that connect are being seen as 127.0.0.1 in Emby so my remote bandwidth limit isn't being enforced.

Do you think this is because my reverse proxy headers are simply wrong or is something else like the issue you described affecting me?

 

 

 

I've been wracking my brain trying to fix it so any help would be really appreciated!

You probably want to check what's going into x-forwarded-for. the server looks at that before checking x-real-ip.

[niallobr 9]

Thanks Luke. So once X-Forwarded-For and X-Real-IP have a value of $remote_addr I should be seeing the remote client IP in Emby instead of 127.0.0.1?

I wonder why that's not working in my case. I've only used nginx a little so any suggestions from anyone would be great. It seems a bit tricky to change the nginx configuration on Synology outside of the GUI as it's getting overwritten on reboot.

[pir8radio 1292]

12 hours ago, niallobr said:

Thanks Luke. So once X-Forwarded-For and X-Real-IP have a value of $remote_addr I should be seeing the remote client IP in Emby instead of 127.0.0.1?

I wonder why that's not working in my case. I've only used nginx a little so any suggestions from anyone would be great. It seems a bit tricky to change the nginx configuration on Synology outside of the GUI as it's getting overwritten on reboot.

@Luke correct me if I'm wrong, but i think the beta only has this fix as of now?  Are you on the beta?

Edited May 27, 2021 by pir8radio

[Luke 37009]

11 minutes ago, pir8radio said:

@Luke correct me if I'm wrong, but i think the beta only has this fix as of now?  Are you on the beta?

No, it's in 4.6 stable.