From: Christoph Liebender <christoph@liebender.dev>
Subject: Re: relayd: add support for PROXY protocol in TCP relays
To: tech@openbsd.org, reyk@openbsd.org
Date: Sun, 9 Nov 2025 11:30:16 +0100

Am 08.11.25 um 22:18 schrieb Kirill A. Korinsky:
> On Sat, 08 Nov 2025 22:00:21 +0100,
> Christoph Liebender <christoph@liebender.dev> wrote:
>>
>> [1  <text/plain; UTF-8 (7bit)>]
>> On 11/8/25 20:20, Christoph Liebender wrote:
>>> Hi tech@,
>>>
>>> I wrote a patch to add support for the PROXY protocol (version 1) [1]
>>> to relayd(8). Works in my usecase where I have a host in a DMZ where
>>> hosts outside of the DMZ connect via a router that NATs their IP into
>>> the DMZs subnet.
>>>
>>> Essentially, what I am trying to mimic is the behavior of the
>>> proxy_protocol directive of nginx's stream proxy module [2].
>>>
>>> I'm more than happy to hear any feedback or comments you have for me :)
>>>
>>> [1] https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
>>> [2] https://nginx.org/en/docs/stream/
>>> ngx_stream_proxy_module.html#proxy_protocol
>>>
>>> PS: I appended my name and email to the copyright notices - also let
>>> me know if that is correct!
>>
>> Whoops! Updated patch with bugfix is attached.
>>
> 
> Any reason why you had implemented only v1 (text) and skip v2 (binary)?
> 

No, there is no apparent reason - I had implemented v1 in op@'s gmid(8) 
(in ports) a while back [1] and still had in mind that v1 is relatively 
straight forward - therefore I initially didn't think about v2 at all.

Also, nginx stream proxy module only speaks version 1. That of course 
doesn't mean relayd needs to be limited to v1... Though v2 probably 
needs more effort and is less trivial to debug.

With v1, one can just nc(1) on a port that relayd forwards to, connect 
to the listen port of relayd and see the proxy line in plaintext.

In my opition, the question about supporting v2 is about:

- does v2 offer any functionality that v1 doesn't while possibly being 
useful for relayd?
- is there any server implementation that relayd would forward to that 
only supports v2, not v1?
- is the added code complexity of v2 worth the "performance benefits" 
that are stated in the v2 spec?

If this patch gets ok'd and in the future, v2 is supposed to be 
supported as well, it probably makes sense to alter the configuration 
syntax to something like:

proxy-protocol v1

to at some point add an option to place a "v2" there.

[1] https://github.com/omar-polo/gmid/pull/30