From owner-freebsd-pf@freebsd.org Mon Jan 9 20:58:43 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 8ED59CA799E for ; Mon, 9 Jan 2017 20:58:43 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B8F012B0 for ; Mon, 9 Jan 2017 20:58:43 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [192.168.228.1] (vega.codepro.be [IPv6:2a01:4f8:162:1127::3]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 06C9B1FE4D; Mon, 9 Jan 2017 21:58:40 +0100 (CET) From: "Kristof Provost" To: "Marek Zarychta" Cc: freebsd-pf@freebsd.org Subject: Re: udp - weird behavior of reply-to Date: Mon, 09 Jan 2017 21:58:38 +0100 Message-ID: In-Reply-To: <20170109172519.GA62580@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: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6072) 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 20:58:43 -0000 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’t ring any bells with me, but I’m >> also >> not sure >> I’ve fully understood it. Can you document a minimal reproduction >> scenario, >> with a pf.conf and perhaps network captures documenting the problem? >> >> There’s certainly not been a conscious decision to break UDP >> reply-to. >> > > Let me apologize, the problem wasn't previously properly identified. > 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 > 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 > 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 0.0.0.0? I’m afraid I’m still struggling to understand what your setup is, what you’re expecting to see and what you’re seeing instead. Regards, Kristof