Add support for haproxy PROXY protocol #494

New Issue

2026-10-05T04:25:02+02:00

adam commented

2026-10-05 04:25:02 +02:00

It would be nice to have haproxy PROXY protocol support, so that znc gets real client IP addresses if haproxy is used to forward client connections to znc instance.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/9167249-add-support-for-haproxy-proxy-protocol?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).

It would be nice to have haproxy [PROXY protocol](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt) support, so that znc gets real client IP addresses if haproxy is used to forward client connections to znc instance. ## <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/9167249-add-support-for-haproxy-proxy-protocol?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam commented

2026-10-05 04:25:03 +02:00

Do you mean, as an alternative to X-Forwarded-For?

Do you mean, as an alternative to X-Forwarded-For?

adam commented

2026-10-05 04:25:04 +02:00

I mean, for IRC client connections.

I mean, for IRC client connections.

adam commented

2026-10-05 04:25:05 +02:00

I feel this is outside of the scope of ZNC and is better suited as a module for ZNC.

I feel this is outside of the scope of ZNC and is better suited as a module for ZNC.

adam commented

2026-10-05 04:25:05 +02:00

I thought ZNC modules have no API to intercept the prologue from incoming TCP socket, no? Haproxy basically prepends client connection details when it connects to ZNC, so this must be handled even earlier than TLS.

I thought ZNC modules have no API to intercept the prologue from incoming TCP socket, no? Haproxy basically prepends client connection details when it connects to ZNC, so this must be handled even earlier than TLS.

adam commented

2026-10-05 04:25:06 +02:00

I presume @DarthGandalf that X-Forwarded-For is currently implemented then, and works for the web interface - but does it work for IRC connections as well?

I imagine if not, then PROXY protocol as mentioned above would be useful for providing the real IP in the actual TCP connection (similar to what happens with Dovecot).

I presume @DarthGandalf that X-Forwarded-For is currently implemented then, and works for the web interface - but does it work for IRC connections as well? I imagine if not, then PROXY protocol as mentioned above would be useful for providing the real IP in the actual TCP connection (similar to what happens with Dovecot).

adam commented

2026-10-05 04:25:07 +02:00

I believe support for X-Forwarded-For header was implemented in #349.

but does it work for IRC connections as well?

X-Forwarded-For is a HTTP header, could you please elaborate how this would apply to the IRC protocol?

I believe support for `X-Forwarded-For` header was implemented in #349. > but does it work for IRC connections as well? `X-Forwarded-For` is a HTTP header, could you please elaborate how this would apply to the IRC protocol?

adam commented

2026-10-05 04:25:07 +02:00

@kylef This is about analog of X-Forwarded-For for any TCP connection, not just HTTP.

@kylef This is about analog of `X-Forwarded-For` for any TCP connection, not just HTTP.

adam commented

2026-10-05 04:25:08 +02:00

This would most likely need to be supported by the upstream CSocket library.

This would most likely need to be supported by the upstream CSocket library.

adam commented

2026-10-05 04:25:09 +02:00

This would most likely need to be supported by the upstream CSocket library.

I have opened jimloco/Csocket#74 to track this.

>This would most likely need to be supported by the upstream CSocket library. I have opened jimloco/Csocket#74 to track this.

adam commented

2026-10-05 04:25:09 +02:00

This could be nice for people exposing their ZNC instance as an onion service, because Tor supports exporting the circuit ID as IPv6 address using haproxy's proxy protocol, which may be a bit more useful than 127.0.0.1.

   HiddenServiceExportCircuitID protocol
       The onion service will use the given protocol to expose the global circuit identifier of each inbound client circuit via the selected protocol.
       The only protocol supported right now 'haproxy'. This option is only for v3 services. (Default: none)

       The haproxy option works in the following way: when the feature is enabled, the Tor process will write a header line when a client is
       connecting to the onion service. The header will look like this:

       "PROXY TCP6 fc00:dead:beef:4dad::ffff:ffff ::1 65535 42\r\n"

       We encode the "global circuit identifier" as the last 32-bits of the first IPv6 address. All other values in the header can safely be ignored.
       You can compute the global circuit identifier using the following formula given the IPv6 address "fc00:dead:beef:4dad::AABB:CCDD":

       global_circuit_id = (0xAA << 24) + (0xBB << 16) + (0xCC << 8) + 0xDD;

       In the case above, where the last 32-bit is 0xffffffff, the global circuit identifier would be 4294967295. You can use this value together with
       Tor’s control port where it is possible to terminate a circuit given the global circuit identifier. For more information about this see
       controls-spec.txt.

       The HAProxy version 1 proxy protocol is described in detail at https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

This could be nice for people exposing their ZNC instance as an onion service, because Tor supports exporting the circuit ID as IPv6 address using haproxy's proxy protocol, which may be *a bit* more useful than `127.0.0.1`. HiddenServiceExportCircuitID protocol The onion service will use the given protocol to expose the global circuit identifier of each inbound client circuit via the selected protocol. The only protocol supported right now 'haproxy'. This option is only for v3 services. (Default: none) The haproxy option works in the following way: when the feature is enabled, the Tor process will write a header line when a client is connecting to the onion service. The header will look like this: "PROXY TCP6 fc00:dead:beef:4dad::ffff:ffff ::1 65535 42\r\n" We encode the "global circuit identifier" as the last 32-bits of the first IPv6 address. All other values in the header can safely be ignored. You can compute the global circuit identifier using the following formula given the IPv6 address "fc00:dead:beef:4dad::AABB:CCDD": global_circuit_id = (0xAA << 24) + (0xBB << 16) + (0xCC << 8) + 0xDD; In the case above, where the last 32-bit is 0xffffffff, the global circuit identifier would be 4294967295. You can use this value together with Tor’s control port where it is possible to terminate a circuit given the global circuit identifier. For more information about this see controls-spec.txt. The HAProxy version 1 proxy protocol is described in detail at https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

adam commented

2026-10-05 04:25:10 +02:00

This will be easier to implement after #1639 is finished

This will be easier to implement after #1639 is finished

adam commented

2026-10-05 04:25:10 +02:00

Any update on this? I've had to reorganize my personal infrastructure onto a cloud provider who doesn't allow for multiple IPs on a single machine so I'm feeling this pain every day :).

Any update on this? I've had to reorganize my personal infrastructure onto a cloud provider who doesn't allow for multiple IPs on a single machine so I'm feeling this pain every day :).

adam commented

2026-10-05 04:25:11 +02:00

If possible it'd also be a good idea to allow this to work with certauth, which I guess it would anyways?

If possible it'd also be a good idea to allow this to work with [certauth](https://wiki.znc.in/Certauth), which I guess it would anyways?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#494