Nginx proxy headers and checking API token allowed IPs

[markkuleinio]

Current NetBox-default nginx.conf suggests this:

proxy_set_header X-Real-IP $remote_addr;
# Example value for client 172.16.16.162:
X-Real-IP: 172.16.16.162

That $remote_addr there is the source IP of the connection Nginx receives. In basic cases that is the NetBox API client's IP address.

This works for API token allowed IP list.

Now, if you are running your NetBox instance behind another reverse proxy, like a load balancer, the X-Real-IP header is populated with the load balancer IP address. In that case the API token allowed IP check fails if you try to use the API client IP there.

Idea: Set the X-Real-IP header with $proxy_add_x_forwarded_for like this:

proxy_set_header X-Real-IP $proxy_add_x_forwarded_for;
# Example value with this config for client 172.16.16.162:
X-Real-IP: 172.16.16.162

I don't know all the details of $proxy_add_x_forwarded_for but it seems to work for the basic case (= no additional reverse proxy/load balancer, the client connects directly to NetBox' Nginx) just fine.

The beauty of using $proxy_add_x_forwarded_for seems to appear when using the additional reverse proxy/load balacer in front of NetBox' Nginx. The header now looks like this:

# Example value for client 172.16.16.162 when connecting through proxy at 10.1.1.10
X-Real-IP: 172.16.16.162, 10.1.1.10
# The first IP is from the X-Forwarder-For header supplied by the first reverse proxy/load balancer

Now the API token allowed IP check works as well: if I configure the token with only 192.168.1.1/32 allowed, I get the error message when accessing the API:

{"detail":"Source IP 172.16.16.162 is not permitted to authenticate using this token."}

But, if I allow the client IP 172.16.16.162(/32) in allowed IP list, it now works through the load balancer as well. So, NetBox/Django parses the first IP address from the X-Real-IP header and uses it when checking the allowed IP list.

So, the question is: Do you see any problem in using $proxy_add_x_forwarded_for instead of $remote_addr by default?

Another question naturally is if something similar exists for Apache as well.

[candlerb]

Another question naturally is if something similar exists for Apache as well.

Apache uses X-Forwarded-For by default - I don't know why Netbox's suggested Nginx config uses X-Real-IP instead.

However there is a wrinkle with multiple proxies, at least last time I checked this (a year or so back). If you go through multiple proxies and Apache sets X-Forwarded-Host to a list of hostnames, Django barfs on this.

So I use the following on the outer proxy so that only X-Forwarded-For is set, and the Host header contains the original target host:

ProxyPreserveHost On
ProxyAddHeaders Off
RequestHeader set X-Forwarded-For "expr=%{REMOTE_ADDR}"

# Further looping safety
ProxyMaxForwards 3

The inner proxy can then set X-Forwarded-Host, and/or add another IP address to X-Forwarded-For, and things work.

[markkuleinio]

Interesting. Based on your examples I removed the X-Real-IP header command from Nginx altogether, and the allowed IP check still works without X-Real-IP. But, there still is the LB-set X-Forwarded-For.

I also tested by faking X-Real-IP.

It seems Django/Netbox uses

1. X-Real-IP if it exists (ignoring X-Forwarded-For)
2. Secondarily X-Forwarded-For

(I bet there is some documentation for this somewhere)

[candlerb]

It's Netbox code (not documented as AFAIK): function get_client_ip() in netbox/utilities/request.py

[markkuleinio]

Well that's it then, I'll start using proxy_set_header X-Real-IP $proxy_add_x_forwarded_for as default with Nginx, as that works in all my implementations right away.