ProxyProtocol support

[AmandaJonesAway]

I'm wondering if it is possible to somehow support passing originating IP/port via Proxy Protocol ?
https://www.haproxy.com/blog/haproxy/proxy-protocol/
I currently have apache passing the connection over to a wstunnel --server instance, which in turn forwards the tcp session to another host on the LAN; The final host now only ever sees the IP of the webserver - the software I'm running supports incoming proxy protocol v2, if it detects the header on connection, so if there is a way to add this (presumably based on whatever apache passes over in the headers) then it'd help enormously in identifying the end-users.
Thanks!

[erebe]

Wstunnel already print X-Forwarded-For header if present, https://github.com/erebe/wstunnel/blob/master/src/Tunnel.hs#L226
Is this not enough ?

[AmandaJonesAway]

This appears in the log, on the server where the wstunnel -server is running, but is not passed on to the final service accepting the connection - this only sees the connection as coming from the IP of the webserver, and has no information as to where it originated. Adding a proxy-protocol header would allow that data to be passed onwards to be logged against the user records on the service using an existing and reasonably well supported mechanism.

[AmandaJonesAway]

I should note that I run a game server, which has both sessions that may last many hours, and resource fetches that last mere moments. It can be very hard to identify which entry in the webserver's log relates to which session on the game server, as the log doesn't include the outgoing port number which I could at least then tie up to the source port on the game server's log, so my only means of tying them together at the moment is by the time initial connection / login occurs, which is relatively course, and might be ambiguous when load is high.

It /should/ only need an appropriate header constructing from the data you have (in, e.g., any X-Forwarded-For) and sending out once ahead of the outgoing connection. But, this is low priority even for me, and I don't expect it to be worked on; just putting it forward as a feature request in case it would be of use to others also.

[erebe]

Haha ok, sorry I read your first message too quickly, I thought you wanted wstunnel server to support proxy protocol from an upstream reverse proxy.

Seems fun to implement, I will try to do it when I have time (which I don't have much those days).
Do you need support for the protocol V1 (text) or V2 (binary) ?

[AmandaJonesAway]

No worries! My server currently supports v2, as it's easier to unpack, so that in preference. :)

…

On Tue, 24 May 2022 at 20:48, Erèbe - Romain Gerard < ***@***.***> wrote: Haha ok, sorry I read your first message too quickly, I thought you wanted wstunnel server to support proxy protocol from an upstream reverse proxy. Seems fun to implement, I will try to do it when I have time (which I don't have much those days). Do you need support for the protocol V1 (text) or V2 (binary) ? — Reply to this email directly, view it on GitHub <#111 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APZV35DT3HNUZKK6TUB5EX3VLUXATANCNFSM5WRV6J3Q> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[erebe]

It has been a long time, but it should be supported now. You can pass to your tcp tunnel -L tcp://1212:192.168.0.1:443?proxy_protocol to send header v2 at the beginning of the connection.

it is in pre-release https://github.com/erebe/wstunnel/releases/tag/v9.1.0

[AmandaJonesAway]

Many thanks! I will update and test, and report back, as soon as I have some free time. (I am confident it will be fine, but I'm always prepared to be surprised by software..)

[erebe]

feel free to re-open if needed