-
-
Notifications
You must be signed in to change notification settings - Fork 100
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
[SOLVED] TLS Proxy: relaying the real client ip #296
Comments
Relaying happens at layer 4. The proxy never decrypts the relayed TLS traffic and is not even able to. But rate limiting is something that can be implemented in the proxy itself. I'm using firewall rules to limit the number of sessions per client IP, but doing it in user land could be easier to configure. |
Thanks for the quick reply.
Relaying happens at layer 4
Granted, how would I go about changing the source address of the relayed tls traffic ? As I understand the upstream server is using the source address to set the http remote ip. Would SNAT work without disturbing the TLS stream ?
For info I am running DoH inside a docker container. All http traffic has as remote ip the DoH sever ip address.
…On November 20, 2024 12:06:43 PM GMT+01:00, Frank Denis ***@***.***> wrote:
Relaying happens at layer 4. The proxy never decrypts the relayed TLS traffic and is not even able to.
But rate limiting is something that can be implemented in the proxy itself. I'm using firewall rules to limit the number of sessions per client IP, but doing it in user land could be easier to configure.
--
Reply to this email directly or view it on GitHub:
#296 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
That would not work without breaking the TCP stream. |
Got it thanks again for the tips. |
@jedisct1 I found a solution and updated the comment for future people who encounter the same problem |
Wow, well done! I didn't know that Caddy could do that! Thanks for the update! |
Hi,
I am running a DoH and relaying https connections to my reverse proxy. All relayed tls traffic has the remote_ip set to the DoH server so implementing any kind of rate/spam control is difficult.
Is there any way I could pass along the real remote client ip when it is proxied ?
Or maybe add an extra header field ?
SOLUTION:
I found a way to bypass specific TLS traffic from dnscrypt server which keeps the original ip packet data. My solution relies and Docker, Caddy-L4 for tls proxy.
The process is roughly the following:
Caddy-l4 http
part. Anything else isTLS Proxied
to the dnscrypt-server.Here is a quick overview of the Caddyfile used with the caddy-l4 docker container:
This would make any tls traffic to
foo.website.com
avoid any extra proxy and keep initial packet data.Note that this Caddyfile only works with Caddy compiled with
caddy-l4
support.The text was updated successfully, but these errors were encountered: