From owner-freebsd-pf@freebsd.org Mon Jan 9 22:17:17 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83C69CA775B for ; Mon, 9 Jan 2017 22:17:17 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [88.199.43.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "plan-b.pwste.edu.pl" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 28BEE1488; Mon, 9 Jan 2017 22:17:16 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (zarychtam@localhost [127.0.0.1]) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPS id v09MHCdk087575 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 9 Jan 2017 23:17:12 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: (from zarychtam@localhost) by plan-b.pwste.edu.pl (8.15.2/8.15.2/Submit) id v09MHCpA087572; Mon, 9 Jan 2017 23:17:12 +0100 (CET) (envelope-from zarychtam) Date: Mon, 9 Jan 2017 23:17:12 +0100 From: Marek Zarychta To: Kristof Provost Cc: freebsd-pf@freebsd.org Subject: Re: udp - weird behavior of reply-to Message-ID: <20170109221712.GA49594@plan-b.pwste.edu.pl> References: <20170108145532.GA17695@plan-b.pwste.edu.pl> <20170109172519.GA62580@plan-b.pwste.edu.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 22:17:17 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 09, 2017 at 09:58:38PM +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 mi= nimal reproduction > >> 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? > > > How are your UDP listen sockets set up? > Are they bound to a specific interface, or are they listening on=20 > 0.0.0.0? Yes, socket is listening on 0.0.0.0, the client from outside network is initiating connection and initiating packet arrives on interface B, which is supposed only to communicate with devices on its own network (no additional routes go via this interface), so normally the reply would be passed via interface A having default gateway in scope and communication would fail. =20 With the assistance of PF reply-to rule, TCP services are able to pass reply from interface B via other, second gateway: reply-to (B GW2).=20 This functionality is currently broken for any UDP service, because UDP sockets are always opened on supposed_to_be_outgoing interface A and bound to the address of this interface, which is considered good from routing table perspective, but silently breaks PF reply-to for UDP. When the machine was running 9-STABLE reply-to had successfully been used to assist both TCP and UDP driven services.=20 Is anyone reading this list still using reply-to rule for routing UDP traffic back via incoming interface? Maybe currently, the better place to discuss this questions would be freebsd-net, but the thread was initiated here. >=20 > I=E2=80=99m afraid I=E2=80=99m still struggling to understand what your s= etup is,=20 > what you=E2=80=99re > expecting to see and what you=E2=80=99re seeing instead. >=20 > Regards, > Kristof --=20 Marek Zarychta --azLHFNyN32YCQGCU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAlh0C+QACgkQdZ/s//1S jSwDDwf/Z5WP6emeAaU2OVU/5hLZzG0t9WoNuGzmk3krqIqiA9MQtQjyq4zPQbXq xk3LS3fpim3IX4vQzww/L5QhaQD+3x1J0YHc+8kYy1+1oLeGDagFCy4WHPav5FRt l6cOn9EvL9nSqSiMvZu2QXjnMyGbx92g79LYU4pysr15Dv4SUFAVqgP0qwdojb8V ++hLaWDM41JPV65ECFJNiOMM/5TfZpff/F5p0bOSU+BHw8Zby13rH+jGqRhFA8XR ppwJrBjUg4E9vpkI2ZMVuSkAXgO1Yg9VD1X3cfUizKs8Gtj1n0MhT3dXro/5OTcJ TN8nyZSmRHQZFw0jaaiD3mYqUlfS3g== =lBju -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU--