From owner-freebsd-bugs@freebsd.org Wed Mar 4 18:07:09 2020 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 56316274E60 for ; Wed, 4 Mar 2020 18:07:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 48Xhfh6ky3z4FCP for ; Wed, 4 Mar 2020 18:07:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id AD2D2274E5F; Wed, 4 Mar 2020 18:07:08 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AB358274E5E for ; Wed, 4 Mar 2020 18:07:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48Xhfh3YhBz4FBF for ; Wed, 4 Mar 2020 18:07:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0BFD621FA6 for ; Wed, 4 Mar 2020 18:07:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 024I77Mw028134 for ; Wed, 4 Mar 2020 18:07:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 024I77Gq028123 for bugs@FreeBSD.org; Wed, 4 Mar 2020 18:07:07 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 244514] "reply-to" function in pf breaks RFC 1122 section 3.3.1.1 Local/Remote Decision Date: Wed, 04 Mar 2020 18:07:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pvz@itassistans.se X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 18:07:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D244514 pvz@itassistans.se changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pvz@itassistans.se --- Comment #8 from pvz@itassistans.se --- I agree with the earlier comment by Kristof Provost. This is not a FreeBSD = bug. pf is being told to route all reply packets back through a certain gateway,= and that is in fact what it's doing. If the way the administrator configures FreeBSD violates an RFC, that's on the administrator. There are many ways to configure firewall rules that go counter to what's written in an RFC, if th= at's what you want to do. It is also conversely possible to configure PF rules that do not cause this behaviour, if that's what you want to do. If a project or system administra= tor that uses pf generates pf rules that end up violating an RFC, it's on whoev= er's or whatever writing the rules to write them differently. In this case the firewall rule is working exactly as intended. You might be able to argue that it would be useful for pf to have a feature that would route packets down a certain interface, as opposed to specifical= ly through a specific gateway, but that would mean talking about introducing a= new feature, rather than changing behaviour of an old one. I think it might be a good idea, but if you really want pf to do that, you can already do that by writing rules that handle same-subnet traffic differently to cross-subnet traffic, although it'd end up a bit messy. Incidentally, I agree with ctminime's core problem description. The way OPNsense and pfSense use this feature is bogus. But it has nothing to do wi= th FreeBSD or pf. It's doing what it's being told, and pf should not second gu= ess what the administrator is telling it to do. There may be good reasons to configure your firewall in that way. --=20 You are receiving this mail because: You are the assignee for the bug.=