RemoteIpAddress and X-Forwarded-For

[Tratcher]

From @JauernigIT on December 12, 2016 12:54

We struggled for some time now to find a way to reliable find out the client IP address in ASP.NET Core...

• Environment: Windows Server 2008 R2, IIS 7.5, ASP.NET Core 1.0.0 (still)
• Requirement: it should work with direct callers as well as with clients that come over a corporate proxy.

First we activated UseIISIntegration() and app.UseForwardedHeaders(new ForwardedHeadersOptions { ForwardedHeaders = ForwardedHeaders.XForwardedFor }) in the startup phase.

Then we thought that we could use httpContext.Connection.RemoteIpAddress for this scenario and yes, it works when we have direct callers - in this case it returns the right client IP... But: unfortunately it doesn't work when the client is behind our corporate proxy. In this case, Connection.RemoteIpAddress everytime returns 127.0.0.1.

Doing some more investigation we found out that the X-Forwarded-For request header was correctly set for clients that come over the proxy: X-Forwarded-For: <client-ip>, 127.0.0.1, <proxy-ip:port>. Hence, we are able to manually grab the right client IP from the request. But we thought that httpContext.Connection.RemoteIpAddress is exactly doing this for us?

Copied from original issue: aspnet/HttpAbstractions#742

[Tratcher]

From @khellang on December 12, 2016 16:56

I think this might be the wrong repo? ForwardedHeadersMiddleware belongs in https://github.com/aspnet/BasicMiddleware 😄

Anyway, have you tried setting the ForwardLimit to something other than 1 (the default) on the ForwardedHeadersOptions?

[Tratcher]

There are a number of other ForwardedHeadersOptions properties to adjust like ForwardLimit and KnownProxies

[JauernigIT]

We tried to set ForwardLimit = null, as result we got the IP address of the proxy back, but not the real client IP...

How is httpContext.Connection.RemoteIpAddress intended to work? Is it evaluating the number of IP addresses in the X-Forwarded-For request header depending on ForwardedHeadersOptions.ForwardLimit? How does it know, which is the outermost IP in the XFF header? As said above, we have an XFF of <client-ip>, 127.0.0.1, <proxy-ip:port>, which has no clear order (but first entry is the client IP). We're using some 3rd party solution for proxying/load balancing, perhaps this doesn't behave in conformity.

[khellang]

@JauernigIT Did you try adding the proxy IP to KnownProxies as well? If the MW doesn't know it's a proxy, it'll assume it's the client IP.

The middleware will process the comma-separated values from right to left. This means that in your case, ForwardLimit should be set to (at least) 3 or null and either the specific proxy IP or an IP-range (which includes the proxy IP) must be added to KnownProxies or KnownNetworks, respectively.

[JauernigIT]

@khellang Thanks, we will test setting KnownProxies on our next deployment. It's not ideal since our network infrastructure changes from time to time, so perhaps we will evaluate X-Forwarded-For manually anyway. Is 127.0.0.1 excluded by default when getting RemoteIpAddress from an XFF chain?

[khellang]

Is 127.0.0.1 excluded by default when getting RemoteIpAddress from an XFF chain?

@JauernigIT Yep. Both IPv4 and IPv6 loopback is in the default list of KnownProxies and KnownNetworks:

BasicMiddleware/src/Microsoft.AspNetCore.HttpOverrides/ForwardedHeadersOptions.cs

Lines 63 to 68 in 46adbc3

	public IList<IPAddress> KnownProxies { get; } = new List<IPAddress>() { IPAddress.IPv6Loopback };
	/// <summary>
	/// Address ranges of known proxies to accept forwarded headers from.
	/// </summary>
	public IList<IPNetwork> KnownNetworks { get; } = new List<IPNetwork>() { new IPNetwork(IPAddress.Loopback, 8) };

[muratg]

@blowdart thoughts?

[blowdart]

Not sure what I'm supposed to be thinking about here. You have to have some knowledge of your network layer to get this configured correctly, there's no way around that.

[Tratcher]

@blowdart The root question on this and related issues is whether or not the algorithm is too complex and requires too many settings for common usage patterns.

[blowdart]

Ah. Maybe. For common use it's usually correct through, it's once you get nested proxies it becomes weird.

[Tratcher]

The defaults only work for IIS/ANCM. Limit one proxy, loopback address, symmetrical headers. It doesn't even work in Azure.

[Tratcher]

https://github.com/aspnet/BasicMiddleware/blob/dev/src/Microsoft.AspNetCore.HttpOverrides/ForwardedHeadersOptions.cs#L51-L74