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://codeberg.org/cybercloud/openbsd-relayd-proxyproto/src/branch/main/patches/current/0001-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://codeberg.org/cybercloud/openbsd-relayd-proxyproto/src/branch/main/patches/current/0001-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