starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Add CONFIG parameter that stores the REAL_IP of the client #6210

New Issue
Closed
opened 2025-12-29 19:38:04 +01:00 by adam · 7 comments
adam commented 2025-12-29 19:38:04 +01:00
Owner
Copy Link

Originally created by @PieterL75 on GitHub (Mar 14, 2022).

NetBox version

v3.1.9

Feature type

New functionality

Proposed functionality

The real IP of a client is currently unknown to netbox. All traffic goes through a reverse proxy (nginx), hiding the original client IP.
We have to create a configurable paramters that identified the HTTP Header that stores the original IP. This is required because not all of the reverse proxies use the same HTTP Header (X-Forwarded-For, X-Real-IP, ...)

This FR will add a new configuration parameter that customizes the HTTP header that stores the real IP of the client.

Proposed Configuration variable name : PROXY_HEADER_REALIP

PROXY_HEADER_REALIP

Default: HTTP_X_REAL_IP

This parameters sets the HTTP Header that contains the REAL IP of a client that connects through a PROXY. The Real IP is required to validate an API token's Allowed IPRanges.
Other common values are HTTP_X_FORWARDED_FOR, HTTP_X_CLIENT_IP

Use case

The FR '#8233 Restrict API key usage by source IP' requires to see the real IP address.
For now a static HTTP Header of 'HTTP_X_REAL_IP is used in that FR, but this needs to be customizable

Database changes

No response

External dependencies

No response

Originally created by @PieterL75 on GitHub (Mar 14, 2022). ### NetBox version v3.1.9 ### Feature type New functionality ### Proposed functionality The real IP of a client is currently unknown to netbox. All traffic goes through a reverse proxy (nginx), hiding the original client IP. We have to create a configurable paramters that identified the HTTP Header that stores the original IP. This is required because not all of the reverse proxies use the same HTTP Header (X-Forwarded-For, X-Real-IP, ...) This FR will add a new configuration parameter that customizes the HTTP header that stores the real IP of the client. Proposed Configuration variable name : PROXY_HEADER_REALIP --- PROXY_HEADER_REALIP Default: HTTP_X_REAL_IP This parameters sets the HTTP Header that contains the REAL IP of a client that connects through a PROXY. The Real IP is required to validate an API token's Allowed IPRanges. Other common values are HTTP_X_FORWARDED_FOR, HTTP_X_CLIENT_IP ### Use case The FR '#8233 Restrict API key usage by source IP' requires to see the real IP address. For now a static HTTP Header of 'HTTP_X_REAL_IP is used in that FR, but this needs to be customizable ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurepending closurestatus: under review labels 2025-12-29 19:38:04 +01:00
adam closed this issue 2025-12-29 19:38:04 +01:00
adam commented 2025-12-29 19:38:04 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 18, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (May 18, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:38:05 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Jun 1, 2022):

I'm good to take this and implement, if approved of course

@PieterL75 commented on GitHub (Jun 1, 2022): I'm good to take this and implement, if approved of course
adam commented 2025-12-29 19:38:05 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 23, 2022):

I don't think this is needed; see what I ended up doing with the get_client_ip() utility function for #8233. There are only three headers (AFAIK) that we need to consider:

  • HTTP_X_REAL_IP
  • HTTP_X_FORWARDED_FOR
  • REMOTE_ADDR

At least one of these should always be defined by the HTTP frontend, so I think this is a reasonable approach.

It's also worth pointing out that this challenge (reliably determining the client IP address) is a very generic "Django problem" rather than something specific to NetBox. I'm happy to defer to whatever is considered best practice by the Django community.

@jeremystretch commented on GitHub (Jun 23, 2022): I don't think this is needed; see what I ended up doing with the [`get_client_ip()` utility function](https://github.com/netbox-community/netbox/blob/f563ba7a9e04af6e985a8f24bf8a3ad66fce168b/netbox/utilities/request.py#L8) for #8233. There are only three headers (AFAIK) that we need to consider: * `HTTP_X_REAL_IP` * `HTTP_X_FORWARDED_FOR` * `REMOTE_ADDR` At least one of these should always be defined by the HTTP frontend, so I think this is a reasonable approach. It's also worth pointing out that this challenge (reliably determining the client IP address) is a very generic "Django problem" rather than something specific to NetBox. I'm happy to defer to whatever is considered best practice by the Django community.
adam commented 2025-12-29 19:38:05 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Jun 23, 2022):

@jeremystretch I think you should leave the option for the admin to choose what http header stores the real ip
Those 3 are indeed the most commen used, but sometimes, you are behind more than one proxy, and a custom headers is set to the first one, so that the backen applications always get the real source ip

@PieterL75 commented on GitHub (Jun 23, 2022): @jeremystretch I think you should leave the option for the admin to choose what http header stores the real ip Those 3 are indeed the most commen used, but sometimes, you are behind more than one proxy, and a custom headers is set to the first one, so that the backen applications always get the real source ip
adam commented 2025-12-29 19:38:05 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 23, 2022):

That can easily be handled within the HTTP frontend configuration.

@jeremystretch commented on GitHub (Jun 23, 2022): That can easily be handled within the HTTP frontend configuration.
adam commented 2025-12-29 19:38:06 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 26, 2022):

I'm going to close this out as it doesn't appear to be needed. Happy to revisit this if we receive actionable feedback for #8233 in the v3.3 release.

@jeremystretch commented on GitHub (Jul 26, 2022): I'm going to close this out as it doesn't appear to be needed. Happy to revisit this if we receive actionable feedback for #8233 in the v3.3 release.
adam commented 2025-12-29 19:38:06 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Jul 26, 2022):

I was actually thinking of this one today...
The best use case, is that admins want to set their own http header to prevent spoofed client ips, when commonly known headers are used.

@PieterL75 commented on GitHub (Jul 26, 2022): I was actually thinking of this one today... The best use case, is that admins want to set their own http header to prevent spoofed client ips, when commonly known headers are used.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label pending closure status: under review type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#6210
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?