Thanks for getting back to it. I've attached the diff directly this time
0001-relayd-proxy-protocol-receive.patch

It already includes your last review round: the header is consumed
incrementally with no event-loop spin, hooked in relay_accept ->
relay_accepted, and proxy-protocol is refused on udp and with a
transparent forward.

Short version of what it does: it lets a relayd(8) listener *receive* a
PROXY header (v1/v2) via a new "proxy-protocol" keyword on the listen line,
so a relay sitting behind a raw-TCP upstream (e.g. an SNI demux that hands
the stream to a local relayd for TLS termination) recovers the real client
address for $REMOTE_ADDR / X-Forwarded-For, source-hash stickiness and
logging. relayd can already emit a PROXY header but couldn't receive one.

I rebased it on today's -current (8.0 snapshot #65): it applies with no
fuzz, builds with no new warnings, links, and "relayd -n" is happy. The one
hunk that had drifted was the F_NATLOOK proc_compose error check in relay.c,
which the rebase keeps in the moved relay_accepted(). The unit harness for
proxy_protocol_read() still passes on all cases (v1/v2, IPv6, LOCAL,
malformed, partial-header anti-spin, byte-by-byte trickle).

It still builds on 7.9 too :)

Thanks again,
Romain

-----Message d'origine-----
De : Kirill A.Korinsky <kirill@korins.ky> 
Envoyé : dimanche 13 septembre 2026 22:58
À : Romain FABBRI <romain.fabbri@alienconsulting.net>
Cc : tech@openbsd.org
Objet : Re: relayd: receive the PROXY protocol (v1 and v2) on listeners

On Wed, 22 Jul 2026 09:25:59 +0200,
Romain FABBRI <romain.fabbri@alienconsulting.net> wrote:
> 
> You're right.  Doing UDP properly needs a separate field for the
> advertised source, leaving se_in.ss as the real peer.  So I've dropped
> UDP and gone back to the earlier shape: TCP reception, with
> proxy-protocol simply refused on udp relays.
> 
> Thanks for the time you spent on it -- it caught real problems and the
> patch is better for it.
> 
> Sorry for the churn, and for adding UDP before it was ready.
> 
> TCP-only diff:
> https://m365.eu.vadesecure.com/safeproxy/v4?f=g0c-4AgzN6IV_tdgQLqXQbFMw74jYOgkxunzPGKPZm_SPpzJeEegGfEkE0HoDRm_&i=M_xjlqQfYYw4fcRWO0RGQLCPy3TRlZf3Ey837CY-4W7SRlC94IYPqkTV0ww0eQwuQWvJaPJGNNClxq0TV3ml-w&k=MOcz&r=SOOkHcOTe-oVAFTTkBM5tV1NLHY_jzmtv1N0yUK5d04w_yJDgrgz9VUslnB0tsT0lLxEZ2ySu9gYuMavfU9Uow&s=ad3ef25ace7a5942a44e10a7d1433b7130d611448cce8e28bc3383ce0151743c&u=https%3A%2F%2Fcodeberg.org%2Fcybercloud%2Fopenbsd-relayd-proxyproto%2Fsrc%2Fbranch%2Fmain%2Fpatches%2Fcurrent%2F0001-relayd-proxy-protocol-receive.patch
>

Sorry, it took me quite a lot of time to be ready to review it.

I had tried to open a link and its gone.

If you still interested in this diff, please resend it, better as attachmet
to avoid dissapeared link again.

Thanks.

> Regards,
> Romain
> 
> -----Message d'origine-----
> De : Kirill A.Korinsky <kirill@korins.ky> 
> Envoyé : lundi 20 juillet 2026 15:09
> À : Romain FABBRI <romain.fabbri@alienconsulting.net>
> Cc : tech@openbsd.org
> Objet : Re: relayd: receive the PROXY protocol (v1 and v2) on listeners
> 
> On Mon, 20 Jul 2026 10:01:13 +0200,
> Romain FABBRI <romain.fabbri@alienconsulting.net> wrote:
> > 
> > 3) UDP.
> > 
> > Right -- and rather than refuse it, I implemented it.  On a UDP relay
> > the header shares the datagram with the payload, as the spec requires,
> > so relay_udp_server() parses it in place, adopts the advertised source
> > and strips it before the payload is handled.  The TCP and UDP paths
> > share one parse function.  I checked it end to end: a datagram carrying
> > a v1 header plus a DNS query reaches the backend stripped of the header,
> > and "log connection" shows the advertised source.
> > 
> > Tested on -current and on 7.9-release: no new warnings, and relayd -n
> > accepts a proxy-protocol listener while still rejecting a transparent
> > forward.  A small unit harness covers v1/v2 (TCP and UDP families),
> > IPv6, LOCAL, bad input, a partial header (consumed, socket left empty)
> > and a byte-by-byte trickle.  The regress tests (v1, v2, and a from-rule
> > filter) pass in copy and splice mode, and I checked by hand that a TLS
> > listener reads the header first and then completes the handshake.
> > 
> > The revised diff (code + regress tests) is here:
> > https://m365.eu.vadesecure.com/safeproxy/v4?f=g0c-4AgzN6IV_tdgQLqXQbFMw74jYOgkxunzPGKPZm_SPpzJeEegGfEkE0HoDRm_&i=M_xjlqQfYYw4fcRWO0RGQLCPy3TRlZf3Ey837CY-4W7SRlC94IYPqkTV0ww0eQwuQWvJaPJGNNClxq0TV3ml-w&k=MOcz&r=SOOkHcOTe-oVAFTTkBM5tV1NLHY_jzmtv1N0yUK5d04w_yJDgrgz9VUslnB0tsT0lLxEZ2ySu9gYuMavfU9Uow&s=ad3ef25ace7a5942a44e10a7d1433b7130d611448cce8e28bc3383ce0151743c&u=https%3A%2F%2Fcodeberg.org%2Fcybercloud%2Fopenbsd-relayd-proxyproto%2Fsrc%2Fbranch%2Fmain%2Fpatches%2Fcurrent%2F0001-relayd-proxy-protocol-receive.patch
> 
> I used diff from commit fd4fadca6e9c4932847a7deb888f432f4dd6f9e8
> 
> I stop only in UDP point, I do not say that this is only one here, but I
> give up and stop doing review after this.
> 
> So, UDP, two points:
> 
> 1. Your new logic literally replaces destination address and that replaced
>    address is used by sendto(), what means that upstream will reply directly
>    to the client, not to the relayd proxy.
> 
> 2. I think that forward to nat lookup will fail on differnet address
>    families, because pxdst is actually ignored.
> 
> -- 
> wbr, Kirill

-- 
wbr, Kirill

• relayd-proxyproto-current.diff (21K)