Date: Sat, 14 Jan 2017 09:26:38 +0100 From: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> To: Kristof Provost <kp@FreeBSD.org> Cc: freebsd-pf@freebsd.org Subject: Re: udp - weird behavior of reply-to Message-ID: <20170114082638.GA84804@plan-b.pwste.edu.pl> In-Reply-To: <FA66629D-C9F8-4466-B91A-78652294F340@FreeBSD.org> References: <20170108145532.GA17695@plan-b.pwste.edu.pl> <E8BB68F1-4784-474A-B5ED-1E861B2975A8@FreeBSD.org> <20170109172519.GA62580@plan-b.pwste.edu.pl> <FA66629D-C9F8-4466-B91A-78652294F340@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Kj7319i9nmIyA2yE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 13, 2017 at 10:54:40PM +0100, Kristof Provost wrote: > On 9 Jan 2017, at 18:25, Marek Zarychta wrote: > > On Sun, Jan 08, 2017 at 07:08:10PM +0100, Kristof Provost wrote: > >> On 8 Jan 2017, at 15:55, Marek Zarychta wrote: > >> The problem description doesn=E2=80=99t ring any bells with me, but I= =E2=80=99m=20 > >> also > >> not sure > >> I=E2=80=99ve fully understood it. Can you document a minimal reproduc= tion > >> scenario, > >> with a pf.conf and perhaps network captures documenting the problem? > >> > >> There=E2=80=99s certainly not been a conscious decision to break UDP= =20 > >> reply-to. > >> > > > > Let me apologize, the problem wasn't previously properly identified. = =20 > > It > > seems to be more problem of UDP protocol implementation than PF issue. > > UDP sockets are opened and bound to address of the outgoing interface > > (interface which has a route to the client). Because the socket is not > > bound to the incoming interface, the PF reply-to rules couldn't be > > evaluated. By the way, TCP sockets are bound to the interface where=20 > > the > > traffic arrives and everything works fine. > > This machine is i386 running 11.0-STABLE r311772 > > > > The problem remains unresolved. Are there any corresponding sysctls > > correcting this behavior and enabling the opportunity to use PF=20 > > assisted > > symmetric routing scenario again? > > > Thinking about this a bit more, I think the behaviour you see is=20 > entirely > correct and expected. We=E2=80=99re talking about datagram sockets, and = as=20 > far as the > kernel is concerned there=E2=80=99s no relationship between the packet=20 > you=E2=80=99ve just > received from address X and the packet you send to host X. There=E2=80=99= s no > established connection. As a result it=E2=80=99s entirely free to choose = its=20 > source > address: you=E2=80=99re simply telling the kernel =E2=80=9CSend this data= to X=E2=80=9D,=20 > you=E2=80=99re not > adding =E2=80=9Cit=E2=80=99s from Y=E2=80=9D. >=20 > If you want this to behave differently I think you=E2=80=99ll have to con= vince=20 > your > application to open a socket per interface (binding it to that=20 > interface), and > reply using the correct socket. >=20 Let me apologize once again. It was application (OpenVPN) issue. After upgrade to newer version, its behavior changed. While the daemon is run in "multihome" mode it should reply with socket address of the interface, which the client originates to. The daemon was misconfigured because while running dual stack IPv4/IPv6 multihomed instance it was trying to respond with IPv4-mapped IPv6 address thus not even evaluating IP_RECVDSTADDR option. Changing configuration option "proto" from "udp" to "udp4" did the job.=20 Netcat couldn't be used in reproduction scenario, as simply app beeing completely unaware of the destination address of the received datagram (not evaluating the IP_RECVDSTADDR socket option at all). Concluding and closing this thread:=20 PF reply-to for UDP protocol still works great!=20 God bless the people keeping code up to date!=20 Thank all trying to help and figure out my weird misconfiguration case. =20 --=20 Marek Zarychta --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAlh54LsACgkQdZ/s//1S jSz+qgf6AgRN4IZJP0K0LGJSUba+UjMjoPk5WIU0jJh+WGm7e9DrmClly+mh0UGg NdsizyCbau1wxFCQl/51S8ermhz4RgcN8cee4gG74b0V3XgYnRD/KeRWKybeSQtq lao7eMNJ5NOvWlK5P5+x4KfocEvH+jcaGEMzLquTSXV8TZY88pgkFIglslUD2lAo RYhfspahGbRUKlIk1c3jIaIVipktUnj4rwOReRBWAgj2swm3v+tJiAe5x74RtwJy q/kU+yJUuBXoiEDRcPKqWYOwDlp4nArahQUdwsWUdRB/A2utnU7wmsZ1EdAQE9aw EHSffSlIgQ8yw/smfb93rNKpVbWM2w== =Nkt4 -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170114082638.GA84804>