Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forward Client Address to Upstream Server #3

Open
iguy0 opened this issue Feb 19, 2020 · 1 comment
Open

Forward Client Address to Upstream Server #3

iguy0 opened this issue Feb 19, 2020 · 1 comment

Comments

@iguy0
Copy link

iguy0 commented Feb 19, 2020

Hi,

I have been browsing around looking for information on how to forward the client ipv4 address to the upstream server in the DoH and DoT configurations.

I have stumbled upon https://www.nginx.com/blog/ip-transparency-direct-server-return-nginx-plus-transparent-proxy/#ip-transparency . I'm not sure if this particular setting might be of any use in this case, but is the closest hint i could find.

How would i go about configuring DoH/DoT with NGINX and having the upstream DNS resolver running on the same server(BIND,PiHole,etc..) and being able to forward the original client IP to the DNS resolver? As of now my setup shows all requests coming from localhost.

Thank you for your impressive njs library.

@TuxInvader
Copy link
Owner

Hi iguy0,

Apologies for my very late reply.... In general you can't use ip transparency with upstream servers unless they are configured to use your NGINX instance as the route back to the client. Usually with internet service this means setting NGINX as the default gateway, but you can use policy based routing in more exotic set ups. However I don't think it would be possible to make this work on a Linux server where the resolver and nginx communicate over localhost, localhost can't be the route back to client. You might get it to work if you put NGINX and the upstream resolver into containers, because then you could configure routing for the resolver to go via NGINX.

If you want this just for logging purposes, then an alternative might be to update the library to add/modify the EDNS.0 client subnet record to hold the full client IP in a /32, and then configure the resolver to log client subnet. You'd still see the client IP as localhost, but the client subnet would contain the actual client IP (eg 192.168.100.10/32).

Cheers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants