From owner-freebsd-pf@freebsd.org Mon Dec 2 02:56:45 2019 Return-Path: Delivered-To: freebsd-pf@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 C3DBA1C228E for ; Mon, 2 Dec 2019 02:56:45 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47R8s81hSyz4Xbt for ; Mon, 2 Dec 2019 02:56:43 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=Message-ID:Subject:To:From:Date:In-Reply-To; bh=EVG/Vfj7QGtXMt3BkAxReA2XIFGmcNpB2iRbLQS9nHY=; b=EUoOVvWAWAfCfPczU2s04aqMLL tobskR2uw4v5896ynvg4P0EAZTQkJE+0LLb70hS2C0DpHN/PoDPRvFH+Vy9nowi1P94AurXJdJZP/ BhmzzHceH/9pAhmO/5RYQXZ9EfOdWsJ/ltAbtGDwUn3VMkxZQy1SxLrqmxEPSrge/+0g=; Received: from vas by admin.sibptus.ru with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1ibbtC-000Po1-Jc for freebsd-pf@freebsd.org; Mon, 02 Dec 2019 09:56:42 +0700 Date: Mon, 2 Dec 2019 09:56:42 +0700 From: Victor Sudakov To: freebsd-pf@freebsd.org Subject: pf's states Message-ID: <20191202025642.GA99174@admin.sibptus.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline X-DKIM-result: pass sibptus.ru User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47R8s81hSyz4Xbt X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=EUoOVvWA; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-8.44 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.34)[ip: (-9.86), ipnet: 2001:19f0:5000::/38(-4.93), asn: 20473(-1.86), country: US(-0.05)]; DKIM_TRACE(0.00)[sibptus.ru:+]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 02 Dec 2019 02:56:45 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear Colleagues, I was asking this question on the freebsd-net mailing list, but I think it would be better to re-ask it here. There is something I cannot understand about pf's notion of state.=20 Consider this very simple example with two interfaces: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D # DMZ 172.16.1.0/24 pass in on $dmz #block in on $dmz from any to 192.168.0.0/16 # Inside 192.168.10.0/24 pass in on $inside =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D While the "block ..." line is commented out, I can "telnet 172.16.1.10 80" = =66rom 192.168.10.3. But when I uncomment the "block ..." line and restart pf, I cannot do that any more. Why is that? My idea was that the "pass in on $inside" creates state so that return traffic from 172.16.1.10:80 to 192.168.10.3:xxxxx should be permitted, but this is not happening so I must be wrong in my understaning how state works. --=20 Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJd5H1qAAoJEA2k8lmbXsY0aJAH/2d5IUdk4bnzj/I/K2+EcgqW Q2kgTKih2LThhyGFG/AAw8YrdXJdobCyyzDpOr9gGOS6qUjx/6Ku7zDFW2HXoD57 zx+gl5o4ztUrvqvzsq/BQkZWQs1fvfAVzmEhPCq2LSP9QWkHucMfOXF/I2RaXKgI CbJuGgZX2WEmMJPNoa7zO+SCfuAUhLXnRwwdypv8cQoAVyX0TmpNXrWydk9wsCkA JDe2g7nTCB8YQR4oh0VExhdhLXuq9LzGcOhbAAAUIm0RJDODE5/is/a4/oHkx4hp ifEtf+hXveeJSrdAYTuVIW1hzPUW7f3WSZLjewPdGjwVBiL/XCF0IiswhbVKmfA= =B905 -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- From owner-freebsd-pf@freebsd.org Mon Dec 2 09:37:03 2019 Return-Path: Delivered-To: freebsd-pf@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 4A8791CBE8E for ; Mon, 2 Dec 2019 09:37:03 +0000 (UTC) (envelope-from maximos@als.nnov.ru) Received: from mx.als.nnov.ru (mx.als.nnov.ru [95.79.102.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47RKkz6BXnz4s5C for ; Mon, 2 Dec 2019 09:36:59 +0000 (UTC) (envelope-from maximos@als.nnov.ru) Received: from [10.4.1.100] by mx.als.nnov.ru with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1ibi8P-000DL1-Vj for freebsd-pf@freebsd.org; Mon, 02 Dec 2019 12:36:50 +0300 Subject: Re: pf's states To: freebsd-pf@freebsd.org References: <20191202025642.GA99174@admin.sibptus.ru> From: Max Message-ID: <90c1b342-b88a-a9bc-d475-4e6cd027f25c@als.nnov.ru> Date: Mon, 2 Dec 2019 12:36:49 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191202025642.GA99174@admin.sibptus.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru X-Rspamd-Queue-Id: 47RKkz6BXnz4s5C X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of maximos@als.nnov.ru designates 95.79.102.161 as permitted sender) smtp.mailfrom=maximos@als.nnov.ru X-Spamd-Result: default: False [-2.28 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.980,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[nnov.ru]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; IP_SCORE(0.00)[country: RU(0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42682, ipnet:95.79.0.0/16, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 02 Dec 2019 09:37:03 -0000 Hello. Is this a complete ruleset? What about "pass out..." rules? You should check other rules since you have no "quick" in your listed rules. The last matching rule decides what action is taken. 02.12.2019 5:56, Victor Sudakov пишет: > Dear Colleagues, > > I was asking this question on the freebsd-net mailing list, but I think > it would be better to re-ask it here. > > There is something I cannot understand about pf's notion of state. > > Consider this very simple example with two interfaces: > > =================================== > # DMZ 172.16.1.0/24 > pass in on $dmz > #block in on $dmz from any to 192.168.0.0/16 > > # Inside 192.168.10.0/24 > pass in on $inside > =================================== > > While the "block ..." line is commented out, I can "telnet 172.16.1.10 80" from 192.168.10.3. > But when I uncomment the "block ..." line and restart pf, I cannot do > that any more. Why is that? > > My idea was that the "pass in on $inside" creates state so that return > traffic from 172.16.1.10:80 to 192.168.10.3:xxxxx should be permitted, > but this is not happening so I must be wrong in my understaning how > state works. > > From owner-freebsd-pf@freebsd.org Mon Dec 2 10:23:26 2019 Return-Path: Delivered-To: freebsd-pf@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 56AF51CCE58 for ; Mon, 2 Dec 2019 10:23:26 +0000 (UTC) (envelope-from artem@viklenko.net) Received: from alf.viklenko.net (alf.viklenko.net [IPv6:2001:470:71:d72::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.viklenko.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RLmX6wRMz4vTN for ; Mon, 2 Dec 2019 10:23:24 +0000 (UTC) (envelope-from artem@viklenko.net) Received: from [10.0.31.12] (ua1.etadirect.net [91.198.140.16] (may be forged)) (authenticated bits=0) by alf.viklenko.net (8.15.2/8.15.2) with ESMTPSA id xB2AN9Rx092487 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Dec 2019 12:23:13 +0200 (EET) (envelope-from artem@viklenko.net) Subject: Re: pf's states To: Max , freebsd-pf@freebsd.org References: <20191202025642.GA99174@admin.sibptus.ru> <90c1b342-b88a-a9bc-d475-4e6cd027f25c@als.nnov.ru> From: Artem Viklenko Organization: Art&Co. Message-ID: <1c3f3105-86c4-e61a-7d81-f4d794773542@viklenko.net> Date: Mon, 2 Dec 2019 12:23:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: <90c1b342-b88a-a9bc-d475-4e6cd027f25c@als.nnov.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (alf.viklenko.net [192.168.32.61]); Mon, 02 Dec 2019 12:23:13 +0200 (EET) X-Rspamd-Queue-Id: 47RLmX6wRMz4vTN X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.64 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[viklenko.net:s=alf-mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[viklenko.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[viklenko.net,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.64)[ipnet: 2001:470::/32(-4.64), asn: 6939(-3.52), country: US(-0.05)]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 02 Dec 2019 10:23:26 -0000 Hi! Check current state-policy - if-bound or floating. If it if-bound, out rules needed. If floating - state should pass traffic in reverse direction. On 02.12.19 11:36, Max wrote: > Hello. > > Is this a complete ruleset? What about "pass out..." rules? You should check > other rules since you have no "quick" in your listed rules. The last matching > rule decides what action is taken. > > 02.12.2019 5:56, Victor Sudakov пишет: >> Dear Colleagues, >> >> I was asking this question on the freebsd-net mailing list, but I think >> it would be better to re-ask it here. >> >> There is something I cannot understand about pf's notion of state. >> >> Consider this very simple example with two interfaces: >> >> =================================== >> # DMZ 172.16.1.0/24 >> pass in on $dmz >> #block in on $dmz from any to 192.168.0.0/16 >> >> # Inside 192.168.10.0/24 >> pass in on $inside >> =================================== >> >> While the "block ..." line is commented out, I can "telnet 172.16.1.10 80" >> from 192.168.10.3. >> But when I uncomment the "block ..." line and restart pf, I cannot do >> that any more. Why is that? >> >> My idea was that the "pass in on $inside" creates state so that return >> traffic from 172.16.1.10:80 to 192.168.10.3:xxxxx should be permitted, >> but this is not happening so I must be wrong in my understaning how >> state works. >> >> > _______________________________________________ > freebsd-pf@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > -- Regards! From owner-freebsd-pf@freebsd.org Mon Dec 2 13:40:49 2019 Return-Path: Delivered-To: freebsd-pf@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 1360B1AA168 for ; Mon, 2 Dec 2019 13:40:49 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47RR8J3MGbz3MY4 for ; Mon, 2 Dec 2019 13:40:48 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=HBhJito1/YZVn0ad71eyg0Pti6owKzWp39X8aIlWcvA=; b=FbOffNoiRyjG8eeEFzj3XYYDSc tDpKcRhV0b31OJqn8pXgfjGUUcbwyJWHdykROAqOyb3OgDO1234XKHjelQUELU4z7kSofgY7ZDK/K +fmX3dlh9supn57GarcwilBm7rmtum6S2PlJyjqmwwsYtqe3+kRzxZfIRez7T0TjK/vM=; Received: from vas by admin.sibptus.ru with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1iblwV-0003jl-6b for freebsd-pf@freebsd.org; Mon, 02 Dec 2019 20:40:47 +0700 Date: Mon, 2 Dec 2019 20:40:47 +0700 From: Victor Sudakov To: freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <20191202134047.GA14183@admin.sibptus.ru> References: <20191202025642.GA99174@admin.sibptus.ru> <90c1b342-b88a-a9bc-d475-4e6cd027f25c@als.nnov.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <90c1b342-b88a-a9bc-d475-4e6cd027f25c@als.nnov.ru> X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47RR8J3MGbz3MY4 X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=FbOffNoi; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-8.45 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.35)[ip: (-9.87), ipnet: 2001:19f0:5000::/38(-4.93), asn: 20473(-1.89), country: US(-0.05)]; DKIM_TRACE(0.00)[sibptus.ru:+]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 02 Dec 2019 13:40:49 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Max wrote: >=20 > Is this a complete ruleset?=20 For this lab, yes, almost complete. There is only one more line,=20 "nat on $outside ...", but strickly speaking, "nat" is not a rule. > What about "pass out..." rules?=20 Why would I need them? In pf, it's "pass" by default. > You should=20 > check other rules since you have no "quick" in your listed rules.=20 1. There are no other rules.=20 2. Even if there were, they should be irrelevant because the "pass in on $inside" rule should create state, and states are processed before rules. > The last matching rule decides what action is taken. The last matching rule on the $inside interface is=20 "pass in on $inside".=20 The last matching rule on the $outside interface is "block in on $dmz from any to 192.168.0.0/16" --=20 Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJd5RRfAAoJEA2k8lmbXsY0IVQH/3uLinEhG3C2k5vhqiv+H8ub zv918ful+2M/vMotzw0QyddUUEOfWFmK/PdUcRWAL9RaOtNzatPKooSSvS/v5stq O/38N+n2/U8aCWzB8dhRMjM91kckGKHy5Tp42D6qGxyXvA/p8Wyx0sO3eevsVgcz j7IvFk0tnWejoECfUTg+whCXHon1Izo9mEYqKNaEoC/U2f2rG5PkfH58mUB3C7Jd ucHJBuJK/CwMydh10mLECEljR0lhM3Qt+lqFWTQpzj19uXnmLspKnwhRrEUGPtX4 T8DmCNMqz2laGVKqD4xS54yN1e1XN99DGYYD/jWICshF9CSVURtsAcfAPzkPQ5w= =aTtq -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From owner-freebsd-pf@freebsd.org Mon Dec 2 13:46:30 2019 Return-Path: Delivered-To: freebsd-pf@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 DC1391AA4B0 for ; Mon, 2 Dec 2019 13:46:30 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47RRGt0yXlz3N0g for ; Mon, 2 Dec 2019 13:46:29 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=j6/BmSnnUGZG3dbf/hwieTOqf/los0Nwxo+QLGneKEI=; b=YD2JhqY9/TA8IuXBYc7ZOlAwgk zGqpAEexsZilJX/ZBlHjVJ4bWSt7O3+YvvqxkEfUEVOjd6cocrtMVO9mjxwzlmPb+KENLXpAIBRPW s1SgF/8RI8Pm4ZDi8w7Fdkpn+2h32K6rmVBlRKfbjkFpkWkRzlVSj1E71iPgBEARGie8=; Received: from vas by admin.sibptus.ru with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1ibm1w-0003li-Gu; Mon, 02 Dec 2019 20:46:24 +0700 Date: Mon, 2 Dec 2019 20:46:24 +0700 From: Victor Sudakov To: Artem Viklenko Cc: Max , freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <20191202134624.GB14183@admin.sibptus.ru> References: <20191202025642.GA99174@admin.sibptus.ru> <90c1b342-b88a-a9bc-d475-4e6cd027f25c@als.nnov.ru> <1c3f3105-86c4-e61a-7d81-f4d794773542@viklenko.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O5XBE6gyVG5Rl6Rj" Content-Disposition: inline In-Reply-To: <1c3f3105-86c4-e61a-7d81-f4d794773542@viklenko.net> X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47RRGt0yXlz3N0g X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=YD2JhqY9; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-8.45 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; IP_SCORE(-3.35)[ip: (-9.87), ipnet: 2001:19f0:5000::/38(-4.93), asn: 20473(-1.90), country: US(-0.05)]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[sibptus.ru:+]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 02 Dec 2019 13:46:30 -0000 --O5XBE6gyVG5Rl6Rj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Artem Viklenko via freebsd-pf wrote: > Hi! >=20 > Check current state-policy - if-bound or floating. I thought it was "floating" by default. > If it if-bound, out rules needed. If floating - state should pass traffic= in=20 > reverse direction. Well, I configured "set state-policy floating" explicitly in pf.conf and no, this did not help. Uncommenting the "block.." rule prevents a tcp connection from 192.168.10.3 to 172.16.1.10:80" - why is that? --=20 Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ --O5XBE6gyVG5Rl6Rj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJd5RWwAAoJEA2k8lmbXsY0cAIH/jVxlldQyZtlT+VDHcMc8Xzg vlMnYeISreUaPeq5fkxdKwj8xkoSrGCDtJ00h2UCqDbaf9Ag74sa6C+s+OXYJMvt OxDPvCv+PIGuRTSjUHkMprH9XDS0yLdaA6aHfDToE/Ymmr7KbpUTbw1cjmNP+lbP u4t4F2boQRjMwprZaOW95ba6cVN13pmXRo5cgMyhPXfRVCV05e8YSoCKd3VAB8sq 7mv++CAEHRSHOFdnBCWn9Y9uqa/KY+T94dOeaXMn30ogKL8s7NSZlcJFipy5eI9h E5r8hOw83ucSfKUiFe+1gcky+aJ7RCzfWMwCo1WG0qz3lXeSx2v0Ua/kZ5X9bt8= =qE2o -----END PGP SIGNATURE----- --O5XBE6gyVG5Rl6Rj-- From owner-freebsd-pf@freebsd.org Mon Dec 2 14:01:12 2019 Return-Path: Delivered-To: freebsd-pf@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 3BFE51AABBE for ; Mon, 2 Dec 2019 14:01:12 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47RRbq5Lngz3NjP for ; Mon, 2 Dec 2019 14:01:11 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=zWw4Ir6y7Ny98qGEB35tQDCKI6acHD9vPInDgZp4cy0=; b=JE8MA+cvbF6PHQM2qgtoHpFg2l NXf1mAdqv1xV5a/0LGmU626SmVEEeJqfFuX36wu29p2UtwMZPKugmeL43si02L2SrJRKmr7hpZfwl DJKlqjBExKkrzQ0obTm7Ks0kgPAS+eFiL9AnK21t8wWE4daEcuYi6ZHI6EKa/48FYU5Q=; Received: from vas by admin.sibptus.ru with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1ibmGE-0003rI-EL for freebsd-pf@freebsd.org; Mon, 02 Dec 2019 21:01:10 +0700 Date: Mon, 2 Dec 2019 21:01:10 +0700 From: Victor Sudakov To: freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <20191202140110.GC14183@admin.sibptus.ru> References: <20191202025642.GA99174@admin.sibptus.ru> <90c1b342-b88a-a9bc-d475-4e6cd027f25c@als.nnov.ru> <20191202134047.GA14183@admin.sibptus.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m51xatjYGsM+13rf" Content-Disposition: inline In-Reply-To: <20191202134047.GA14183@admin.sibptus.ru> X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47RRbq5Lngz3NjP X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=JE8MA+cv; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-8.45 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.35)[ip: (-9.87), ipnet: 2001:19f0:5000::/38(-4.93), asn: 20473(-1.91), country: US(-0.05)]; DKIM_TRACE(0.00)[sibptus.ru:+]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 02 Dec 2019 14:01:12 -0000 --m51xatjYGsM+13rf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Victor Sudakov wrote: > Max wrote: > >=20 > > Is this a complete ruleset?=20 >=20 > For this lab, yes, almost complete. There is only one more line,=20 > "nat on $outside ...", but strickly speaking, "nat" is not a rule. Just commented out the "nat ..." line. Now there really are 3 lines in pf.conf. Did not help with the issue. --=20 Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ --m51xatjYGsM+13rf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJd5RkmAAoJEA2k8lmbXsY0tkEIAIqoQ8CBCd+ycGusMXRGS/xD QG+BlW75uqdEdjHBc0C1D+JyGPwIvoDOjvBc4bLDq4r3Nv8LQsXu6wQ6/MHSMN1l BaLE6/lKzYG0N9xDwdGCV8eU8h8qsaP94vRlos8rwEC3xthpjw9Vk0YNJH5NXGLm XiNpNCGT5c/ALCtxr5xo7q1D55YclkaNxK9SpC8BBZJo3AOtbEYjTW9hVXOTVwNR UF+0mr697hR7uMukSC5kYahoLmvr4dh0PXpDROUcxp9w9LQmFAZdN5sPb1Iqs4n5 U5vfiJmke1Plr8nUMcFE5F9uSmsKT4rv0D1djK4FpuX9YxNSfg/xyM4IThnaHME= =IySS -----END PGP SIGNATURE----- --m51xatjYGsM+13rf-- From owner-freebsd-pf@freebsd.org Mon Dec 2 14:18:15 2019 Return-Path: Delivered-To: freebsd-pf@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 4C18F1AB253 for ; Mon, 2 Dec 2019 14:18:15 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RRzV1tRYz3PXp for ; Mon, 2 Dec 2019 14:18:13 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: by mail-ed1-x541.google.com with SMTP id cx19so24564591edb.1 for ; Mon, 02 Dec 2019 06:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxpowered-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=EuTDDtSFN/GsQ4fE+Yu5fkC7XK+xoeXdr0idnPGnMY8=; b=Z0PRoWhGdRdEi3d0QiD1po0x2vrt7/cb7wrzMZkmLx/1d1vRu/acMYhgX170nMRWjv ffz+KLNFQ73D4eCi3BCAHJtePSvBHRWkGPkhUASVmTbtcRGoyHS5DEsTAMQh1c0FmZT4 K0FlENb/OToF5VpPeeWdmgzxQ6I4CpH0RODfWzqigyYdFh1IaputFAMl2JOxt91ft6vq GvrOkOWUe8fOCFuWVVRuAWRzun9ti7yeO6jdw0x1g2HhshXNvX4qdPQSe5McedNnYF/K 6wRp8ufUx76nvLug0+7dmlFtjoOFsH9/BBo5rnCFdMBuF0/xgluxtq4F7ShZ0mcRBG/s FeZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=EuTDDtSFN/GsQ4fE+Yu5fkC7XK+xoeXdr0idnPGnMY8=; b=HRpNDrTJy9XIKgSikGLUI0zNv2Xz+vMX646M10SNxLvSIezmBd0aa7FX/vcdHwKh7L d6l+LPu7VKOTHghzw/NUkc08BNXa+SceQljaoF8GKI0FIJ4nPAO8kMSKZXIo30ruO8l9 0cLhYg1z6lT8X2dD5WpMG0CxjRvXHicHeo2fG8BMTgHZj/UqXbdjmXsaEEkaxA7gwk7C iGulv9obfcg2I4H9YYccEzVU0sE9FCKvJ/V71RUVYIWeSf/IVmO9UmuSIKwMi8w5NrU6 /J5bdimgMWjzL86TOH6VA14q6Sr0QKfyb1XnGPDJ+2hLDeDLSeyJ0zE+ntNgoIMdDri8 NPjA== X-Gm-Message-State: APjAAAUs5+TPLLjX7HiD6J/ooVh81beCq43oEDLDSqOWu6z9mcKWHOiV ahh7jrkdSQJH+MILNOgTBF/E8pd64sA= X-Google-Smtp-Source: APXvYqxkVlGM1oz6ajxCr/AHb28OcQECcYi15C2waC52YxpI6Kco6DKUBlh4XdP6AMjPPK87uA0JDg== X-Received: by 2002:a05:6402:1d2d:: with SMTP id dh13mr10410004edb.128.1575296291669; Mon, 02 Dec 2019 06:18:11 -0800 (PST) Received: from Proton.local ([2a00:1f78:fffb:1000:a5c3:87f2:2105:a730]) by smtp.gmail.com with ESMTPSA id i14sm1540774edk.65.2019.12.02.06.18.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Dec 2019 06:18:10 -0800 (PST) Subject: Re: pf's states To: freebsd-pf@freebsd.org References: <20191202025642.GA99174@admin.sibptus.ru> <90c1b342-b88a-a9bc-d475-4e6cd027f25c@als.nnov.ru> <1c3f3105-86c4-e61a-7d81-f4d794773542@viklenko.net> From: Kajetan Staszkiewicz Openpgp: preference=signencrypt Autocrypt: addr=vegeta@tuxpowered.net; keydata= mQGiBELvVycRBADVGZM8mHAsH+R87EBg4O+QTOkL0TjroqamohMlCdBEZgFGcGVoKA9c9Az6 e7xpk90DuaWYrzBKJ+I5drx2ddqdqejLhgNm3QZubE8Cf9cCxBAxnxBZHzmmgVJMOg93lJUQ e9L1BstntodE2xz4jSBB++Zh9eZgRqbn/EICcQmmKwCg9pQfnXRAMr4tFxhsFenxa/JCvFME AK/03irNfB8DezORCfpt7lZuwL5oRJ/TvpoCfwgVkNd6gTLMgSQpKbFytLzAAmRsE+EwVpBo sUzKt4vzmW4bllgPao14TyuVcViah27/da3fHm1HIMkjvro/ONtUivInn+5L33S0meT3KyuK ofwc1A6KucNxhv4rG7RsXuhwZZmQA/0QVni2wq7yc6t15dfCxuDCxG7yXp4pE5Dghp/MMwts leIxJ3JdHaTZ9aIrYT2Rxw8mTXUs89pDi7PCqXA2N4C+RvkoZI0Q6cWs6jHNZGiZRVzkw38r 8ctqtAlcfzlAynX5+Ym9oiNMJ/c/4fAiFrWerMR1rFWDSD56ltQHk0X0oLQsS2FqZXRhbiBT dGFzemtpZXdpY3ogPHZlZ2V0YUB0dXhwb3dlcmVkLm5ldD6IewQTEQIAOwYLCQgHAwIDFQID AxYCAQIeAQIXgAIZARYhBI4RBk5u/YHyZ/QlueO0UK9tezoUBQJcD656BQkbAXUJAAoJEOO0 UK9tezoUnsIAoK89eXWiO7x3gkfC+5mDXNnRx6ioAKCy4NE/0s8vTDA/P3yYJ2r6orDDNLkB DQRC71cpEAQAjXEOKfj9O4eYTWcifEApMYzel9+aWmhNRqqUhJuNO40UDF73biRJ0cjd8miV hZGxcqIdjnZUmxn8Okr+ta7ZU4Q2KNw7B23VKd1jzDKalaUGtCbv8pnvFdBCJwwzdhHJ2vxr e7zkGMrU4x5Od/92YZRCgX229Ic8y7muveQty4sAAwYD/A/FKDQkIu16GVOu9g8ZBLLBi1HS h2eiem/efmfZS1APR7Q5Ouf6KJMeEgBCKY9yqEp9wg97Bt93oi3zP0H1I8rLmrj5hoEE/VEj Cc4XSQ3qrthmQ9bE8fPDZIgodPG1h+dlOzDQoUxKM/YZdbKmV8VkegbAmEng9rJk90gJ+7Qt iGMEGBEIACMWIQSOEQZObv2B8mf0JbnjtFCvbXs6FAUCXDcogwUJGzo2agAKCRDjtFCvbXs6 FNsqAJ9naj/37JF2c1HjhO/4xosKOtGX/QCgn5ADg8fykMSnWmIR0GO/xq9LEzs= Message-ID: <9c221ef5-e300-378b-1db8-6de18e652000@tuxpowered.net> Date: Mon, 2 Dec 2019 15:18:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <1c3f3105-86c4-e61a-7d81-f4d794773542@viklenko.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h3nJttgxjvwz9GeQGvURhVmshlkWT3HOd" X-Rspamd-Queue-Id: 47RRzV1tRYz3PXp X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tuxpowered-net.20150623.gappssmtp.com header.s=20150623 header.b=Z0PRoWhG; dmarc=none; spf=pass (mx1.freebsd.org: domain of vegeta@tuxpowered.net designates 2a00:1450:4864:20::541 as permitted sender) smtp.mailfrom=vegeta@tuxpowered.net X-Spamd-Result: default: False [-5.54 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[tuxpowered-net.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; TO_DN_NONE(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[tuxpowered.net]; DKIM_TRACE(0.00)[tuxpowered-net.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[1.4.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; IP_SCORE(-0.94)[ip: (-0.02), ipnet: 2a00:1450::/32(-2.69), asn: 15169(-1.94), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 02 Dec 2019 14:18:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h3nJttgxjvwz9GeQGvURhVmshlkWT3HOd Content-Type: multipart/mixed; boundary="i4J4Z9vQTq29AfnI3s6TdQ8sXLPfVP3G3"; protected-headers="v1" From: Kajetan Staszkiewicz To: freebsd-pf@freebsd.org Message-ID: <9c221ef5-e300-378b-1db8-6de18e652000@tuxpowered.net> Subject: Re: pf's states References: <20191202025642.GA99174@admin.sibptus.ru> <90c1b342-b88a-a9bc-d475-4e6cd027f25c@als.nnov.ru> <1c3f3105-86c4-e61a-7d81-f4d794773542@viklenko.net> In-Reply-To: <1c3f3105-86c4-e61a-7d81-f4d794773542@viklenko.net> --i4J4Z9vQTq29AfnI3s6TdQ8sXLPfVP3G3 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 02.12.19 11:23, Artem Viklenko via freebsd-pf wrote: > Hi! >=20 > Check current state-policy - if-bound or floating. > If it if-bound, out rules needed. If floating - state should pass > traffic in reverse direction. That's not true. Created pf states will always match bidirectional traffic. State-bound means that finding existing state of incoming packet is done not by normal TCP/IP quadruple but also incoming interface is checked. Floating is useful when you have a router and given TCP session can move from one uplink to another. Packets will still match connection established before. Interface-bound is useful if you have traffic passing twice via the same router, two ways. For example you run pf on a douter and one host behind the router wants to talk to another host behind the same router, but traffic is not routed by this router itself but always sent to another router. In this case packet incoming from originating host would be indistinguishable from packed bounced back by upstream router if not for interface being added to state key. --=20 | pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------' --i4J4Z9vQTq29AfnI3s6TdQ8sXLPfVP3G3-- --h3nJttgxjvwz9GeQGvURhVmshlkWT3HOd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSOEQZObv2B8mf0JbnjtFCvbXs6FAUCXeUdIAAKCRDjtFCvbXs6 FFokAJ4s7W8McXIPDVDjkKmiPfFYZ6IdigCeLgElAB3MvoaOx648G/tTuHRBlEs= =KP5C -----END PGP SIGNATURE----- --h3nJttgxjvwz9GeQGvURhVmshlkWT3HOd-- From owner-freebsd-pf@freebsd.org Mon Dec 2 14:59:29 2019 Return-Path: Delivered-To: freebsd-pf@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 18B731AC5C5 for ; Mon, 2 Dec 2019 14:59:29 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RSv41mrvz3wks for ; Mon, 2 Dec 2019 14:59:27 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: by mail-ed1-x52c.google.com with SMTP id cy15so24853330edb.4 for ; Mon, 02 Dec 2019 06:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxpowered-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=hHTBILDQLmyi8feFHsNafOTf99VO4ZtviPfX8kcCnX8=; b=cNssDQ2E940lV3+L8zMM2FcWdrN4dAN9uSBcX5boLKwzdlW6ojnHt9a+UDf6Wb5mmr zNZfxotlbK0/kZTflBcV5kfzPZoByU7mH7OXbIyZDtelZ2zIXXRnIcMPazQnKZgj4JHC fSQorhaxzb6RZ10U2Ti9ogEZXXNihhw7aDmJ4RQbYyOCYdwsCa1+Q5N/kTy/Le4fxtnz K9/qTTbue9XUSSamc+3a+/cl/9qM3tFWg3N/pEvrM72/R1+f/TDULkjgnGnSdJrxzzHB i3NLyU56gsj7hyn/Yb4734EmBc2Mx5TiAB9AczoZxfpUKcHSS8JuvnZfE2zsABkrCkGD mV9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=hHTBILDQLmyi8feFHsNafOTf99VO4ZtviPfX8kcCnX8=; b=LWk24VafVni24R10NH9N5DF/gYZSQWVeBNIaZOVMU3OmjILKw+khCJxXdbmpiQybVn xDBUxTBLo9nuRv3Lx/VK1Ge54F7a3GXV0IrzXIH+bJhJ2hFS/82CZGgYIRQM03/IXcJG 5crj96on5oehWJA8FVA/Km6LtsxlcPuPvvkL+j6WvAInK++tlJzBTIPR7zv9qd4g2VXK fBcordGOuoOzEPKNuqGyfOgKNADYFPfjSjHd+PhCr2rU/lbLqk4cnrIcLRSuDI4QOIVe 2ugznU8AGcp/mLevOsf5tkZ0nzne7x5ICOjPsS4Mcpdf89zq+C68wYVm47gNPzk7DKI9 teyA== X-Gm-Message-State: APjAAAXCIAw/Ge9Ja+Lzsa/VZBesgoofrYUNP8JspbWDkOqRrEO/M+7o 6zuCsDAZcNP/Lwz6kuRS2zKizgN0f1I= X-Google-Smtp-Source: APXvYqza7ECW1zXg2qwapB0baq7EhtjxSIWVeM1Dhv3czTAQbjyH+pJ/I2qA+5JsfaISZLbyL5iWoQ== X-Received: by 2002:a17:906:a950:: with SMTP id hh16mr4555655ejb.75.1575298763333; Mon, 02 Dec 2019 06:59:23 -0800 (PST) Received: from Proton.local ([2a00:1f78:fffb:1000:a5c3:87f2:2105:a730]) by smtp.gmail.com with ESMTPSA id cn26sm362867edb.83.2019.12.02.06.59.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Dec 2019 06:59:22 -0800 (PST) Subject: Re: pf's states To: freebsd-pf@freebsd.org References: <20191202025642.GA99174@admin.sibptus.ru> From: Kajetan Staszkiewicz Openpgp: preference=signencrypt Autocrypt: addr=vegeta@tuxpowered.net; keydata= mQGiBELvVycRBADVGZM8mHAsH+R87EBg4O+QTOkL0TjroqamohMlCdBEZgFGcGVoKA9c9Az6 e7xpk90DuaWYrzBKJ+I5drx2ddqdqejLhgNm3QZubE8Cf9cCxBAxnxBZHzmmgVJMOg93lJUQ e9L1BstntodE2xz4jSBB++Zh9eZgRqbn/EICcQmmKwCg9pQfnXRAMr4tFxhsFenxa/JCvFME AK/03irNfB8DezORCfpt7lZuwL5oRJ/TvpoCfwgVkNd6gTLMgSQpKbFytLzAAmRsE+EwVpBo sUzKt4vzmW4bllgPao14TyuVcViah27/da3fHm1HIMkjvro/ONtUivInn+5L33S0meT3KyuK ofwc1A6KucNxhv4rG7RsXuhwZZmQA/0QVni2wq7yc6t15dfCxuDCxG7yXp4pE5Dghp/MMwts leIxJ3JdHaTZ9aIrYT2Rxw8mTXUs89pDi7PCqXA2N4C+RvkoZI0Q6cWs6jHNZGiZRVzkw38r 8ctqtAlcfzlAynX5+Ym9oiNMJ/c/4fAiFrWerMR1rFWDSD56ltQHk0X0oLQsS2FqZXRhbiBT dGFzemtpZXdpY3ogPHZlZ2V0YUB0dXhwb3dlcmVkLm5ldD6IewQTEQIAOwYLCQgHAwIDFQID AxYCAQIeAQIXgAIZARYhBI4RBk5u/YHyZ/QlueO0UK9tezoUBQJcD656BQkbAXUJAAoJEOO0 UK9tezoUnsIAoK89eXWiO7x3gkfC+5mDXNnRx6ioAKCy4NE/0s8vTDA/P3yYJ2r6orDDNLkB DQRC71cpEAQAjXEOKfj9O4eYTWcifEApMYzel9+aWmhNRqqUhJuNO40UDF73biRJ0cjd8miV hZGxcqIdjnZUmxn8Okr+ta7ZU4Q2KNw7B23VKd1jzDKalaUGtCbv8pnvFdBCJwwzdhHJ2vxr e7zkGMrU4x5Od/92YZRCgX229Ic8y7muveQty4sAAwYD/A/FKDQkIu16GVOu9g8ZBLLBi1HS h2eiem/efmfZS1APR7Q5Ouf6KJMeEgBCKY9yqEp9wg97Bt93oi3zP0H1I8rLmrj5hoEE/VEj Cc4XSQ3qrthmQ9bE8fPDZIgodPG1h+dlOzDQoUxKM/YZdbKmV8VkegbAmEng9rJk90gJ+7Qt iGMEGBEIACMWIQSOEQZObv2B8mf0JbnjtFCvbXs6FAUCXDcogwUJGzo2agAKCRDjtFCvbXs6 FNsqAJ9naj/37JF2c1HjhO/4xosKOtGX/QCgn5ADg8fykMSnWmIR0GO/xq9LEzs= Message-ID: <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> Date: Mon, 2 Dec 2019 15:59:21 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191202025642.GA99174@admin.sibptus.ru> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dROpFXdnOibHxjLkOM25A2EYr9q12AHUI" X-Rspamd-Queue-Id: 47RSv41mrvz3wks X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tuxpowered-net.20150623.gappssmtp.com header.s=20150623 header.b=cNssDQ2E; dmarc=none; spf=pass (mx1.freebsd.org: domain of vegeta@tuxpowered.net designates 2a00:1450:4864:20::52c as permitted sender) smtp.mailfrom=vegeta@tuxpowered.net X-Spamd-Result: default: False [-7.45 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[tuxpowered-net.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; TO_DN_NONE(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[tuxpowered.net]; DKIM_TRACE(0.00)[tuxpowered-net.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[c.2.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; IP_SCORE(-2.85)[ip: (-9.56), ipnet: 2a00:1450::/32(-2.69), asn: 15169(-1.94), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 02 Dec 2019 14:59:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dROpFXdnOibHxjLkOM25A2EYr9q12AHUI Content-Type: multipart/mixed; boundary="dYya6WJAZm50C03ztUDVdrmjkzbO9oXFa"; protected-headers="v1" From: Kajetan Staszkiewicz To: freebsd-pf@freebsd.org Message-ID: <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> Subject: Re: pf's states References: <20191202025642.GA99174@admin.sibptus.ru> In-Reply-To: <20191202025642.GA99174@admin.sibptus.ru> --dYya6WJAZm50C03ztUDVdrmjkzbO9oXFa Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 02.12.19 03:56, Victor Sudakov wrote: > Dear Colleagues, >=20 > I was asking this question on the freebsd-net mailing list, but I think= > it would be better to re-ask it here. >=20 > There is something I cannot understand about pf's notion of state.=20 >=20 > Consider this very simple example with two interfaces: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > # DMZ 172.16.1.0/24 > pass in on $dmz > #block in on $dmz from any to 192.168.0.0/16 >=20 > # Inside 192.168.10.0/24 > pass in on $inside > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > While the "block ..." line is commented out, I can "telnet 172.16.1.10 = 80" from 192.168.10.3. For initial SYN of TCP connection from 192.168.10.3 to 172.16.1.10 rule evaluation looks like below. Returning SYN+ACK and all further packets will be matched against states. It is not possible with pf to skip matching to existing states. It's done in code before ruleset evaluation.= Your initial SYN is "in" on $inside and "out" on $dmz, correct? Rule 1 does not match this packet Rule 3 matches said packet, action is PASS > But when I uncomment the "block ..." line and restart pf, I cannot do > that any more. Why is that? Then it looks like this: Rule 1 does not match this packet Rule 2 does not match this packet Rule 3 matches said packet, action is PASS There should be no difference. Are you sure you're talking about connection from $inside to $dmz and that variables are not swapped? And are you sure you're making a new TCP connection and not just talking about the old one being terminated? Restarting pf (service pf restart) will terminate existing states. All existing tcp connections will either immediately reset or timeout, depending on other conditions. In most cases you don't want to restart pf but only apply new ruleset. Unless you want to restart. That depends on your security considerations because reloading new ruleset keeps existing sessions so even if you remove them from firewall, users connected before that over, let's say ssh, will still remain connected. > My idea was that the "pass in on $inside" creates state so that return > traffic from 172.16.1.10:80 to 192.168.10.3:xxxxx should be permitted, > but this is not happening It should be like this, yes. > so I must be wrong in my understaning how > state works. Please remember that pf on a router creates 2 states: one before routing, one after. Existing states and ruleset are evaluated twice. First state will be "in on $iface1" and the other "out on $iface2". Both states might be created by same rule if you don't provide "on $iface" in rule and only operate on IP addresses. The last thing I would like to point out is that your firewall lacks final blocking rule. Designing firewalls by mixing passes and blocks is generally a bad idea. It's way safer to provide a single blocking rule for all traffic on all interfaces and then allow only some subsets of traffic. --=20 | pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------' --dYya6WJAZm50C03ztUDVdrmjkzbO9oXFa-- --dROpFXdnOibHxjLkOM25A2EYr9q12AHUI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSOEQZObv2B8mf0JbnjtFCvbXs6FAUCXeUmyQAKCRDjtFCvbXs6 FJ5HAJ9oBmKfZhimqxtVWBGVBsQcIhTzUQCg435oHpYJr5k/JRYwbdahlRXkOgQ= =nx+s -----END PGP SIGNATURE----- --dROpFXdnOibHxjLkOM25A2EYr9q12AHUI-- From owner-freebsd-pf@freebsd.org Mon Dec 2 15:25:45 2019 Return-Path: Delivered-To: freebsd-pf@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 3922F1AD329 for ; Mon, 2 Dec 2019 15:25:45 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47RTTN2M64z3y5H for ; Mon, 2 Dec 2019 15:25:44 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=Wg+c02US6IPU6Y2tPrkoU0OrB6nJqP77fZvsu/xrEQU=; b=V4Ofv0vRXJrRFXXW0cPXgd/9Z3 ezFAGMwXc+ZBpj1pzUm3wD2YiNOaj9H9Wv1M16v+2u6cVxJuuUmNyfmC8R8GLKdJpIKW/RXOk09Fa asSkU8Zmo12G6SH+XAACpILi5k5FRteCNox2+l48nXMLs2HAHeRTxWsK2U5gKdneeGO0=; Received: from vas by admin.sibptus.ru with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1ibna3-0004K5-1V for freebsd-pf@freebsd.org; Mon, 02 Dec 2019 22:25:43 +0700 Date: Mon, 2 Dec 2019 22:25:43 +0700 From: Victor Sudakov To: freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <20191202152543.GA16128@admin.sibptus.ru> References: <20191202025642.GA99174@admin.sibptus.ru> <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47RTTN2M64z3y5H X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=V4Ofv0vR; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-8.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.36)[ip: (-9.87), ipnet: 2001:19f0:5000::/38(-4.93), asn: 20473(-1.92), country: US(-0.05)]; DKIM_TRACE(0.00)[sibptus.ru:+]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 02 Dec 2019 15:25:45 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kajetan Staszkiewicz wrote: > >=20 > > I was asking this question on the freebsd-net mailing list, but I think > > it would be better to re-ask it here. > >=20 > > There is something I cannot understand about pf's notion of state.=20 > >=20 > > Consider this very simple example with two interfaces: > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > # DMZ 172.16.1.0/24 > > pass in on $dmz > > #block in on $dmz from any to 192.168.0.0/16 > >=20 > > # Inside 192.168.10.0/24 > > pass in on $inside > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > While the "block ..." line is commented out, I can "telnet 172.16.1.10 = 80" from 192.168.10.3. >=20 > For initial SYN of TCP connection from 192.168.10.3 to 172.16.1.10 rule > evaluation looks like below. Returning SYN+ACK and all further packets > will be matched against states. It is not possible with pf to skip > matching to existing states. It's done in code before ruleset evaluation. >=20 > Your initial SYN is "in" on $inside and "out" on $dmz, correct? I hope it's correct. I sit on the box 192.168.10.3 and telnet to 172.16.1.1= 0. >=20 > Rule 1 does not match this packet > Rule 3 matches said packet, action is PASS Rule 2 matches said packet, because commenting out the "block..." rule leaves only 2 rules in "pfctl -s rules" >=20 > > But when I uncomment the "block ..." line and restart pf, I cannot do > > that any more. Why is that? >=20 > Then it looks like this: > Rule 1 does not match this packet > Rule 2 does not match this packet > Rule 3 matches said packet, action is PASS And Rule 3 should create state to pass return packets back from 172.16.1.10:80 to 192.168.10.3, correct?=20 >=20 > There should be no difference. Are you sure you're talking about > connection from $inside to $dmz and that variables are not swapped? Yes, I'm sure. >=20 > And are you sure you're making a new TCP connection and not just talking > about the old one being terminated? Yes, I'm sure. I try to open a new telnet session from 192.168.10.3=20 after running "vi /etc/pf.conf ; service pf restart" on the firewall. [dd] >=20 > > My idea was that the "pass in on $inside" creates state so that return > > traffic from 172.16.1.10:80 to 192.168.10.3:xxxxx should be permitted, > > but this is not happening >=20 > It should be like this, yes. But it's not happening. Do you care to reproduce my problem? You'll need 3 boxes, they may be VMs. In my case, 192.168.10.3 is a real Windows box, the firewall is a real box, and 172.16.1.10 is a bhyve VM on the same firewall (so $dmz is a bridg= e0 interface on the firewall). >=20 > > so I must be wrong in my understaning how > > state works. >=20 > Please remember that pf on a router creates 2 states: one before > routing, one after. Existing states and ruleset are evaluated twice. > First state will be "in on $iface1" and the other "out on $iface2". Both > states might be created by same rule if you don't provide "on $iface" in > rule and only operate on IP addresses. This is not the case here. All the 2 (or 3) rules are bound to interfaces. >=20 > The last thing I would like to point out is that your firewall lacks > final blocking rule.=20 It's not a real world firewall, really. It's an example for understanding pf's concept of statefulness, and I must admit I'm puzzled. --=20 Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ --DocE+STaALJfprDB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJd5Sz3AAoJEA2k8lmbXsY0QWwH/1fVcL5IeZVkhKX9eTlc8rXY fmF3fvJCKinOHWbAUXANwA+bIEHYzLrYpjhJv94BX0R0rvFqVc6ShKfmv4qrWHxE B+VwJ+ozn1IkcYkKc7GXYUf9S6wB0Tzx8kzdrvGUb9hVEmEwle/POj/t7K9m6YId Hk8GF3HNtKoN3bj2hNjTE0dFOsdpuKlgLCG7ttP43TK3B/HbsJyxpkxTKk1Rov+0 4OIiBLdVb/ktPpBvBwEqjXUSToW4l5FcI/HYLDdy6DS/8G0EfuP5icoRxlg+b0oh DBwQ8WltOYEDDMwRZrYUbm2RPi0Kf/qsyTmmZeoWhyNsLiTcqmR/WoyUyStIwfU= =BmI5 -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- From owner-freebsd-pf@freebsd.org Mon Dec 2 19:19:09 2019 Return-Path: Delivered-To: freebsd-pf@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 218BE1B4321 for ; Mon, 2 Dec 2019 19:19:09 +0000 (UTC) (envelope-from freebsd-database@pp.dyndns.biz) Received: from keymaster.local (ns1.xn--wesstrm-f1a.se [IPv6:2a00:d880:5:1b9::8526]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "keymaster.pp.dyndns.biz", Issuer "keymaster.pp.dyndns.biz" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RZfg6r5qz4F8q for ; Mon, 2 Dec 2019 19:19:07 +0000 (UTC) (envelope-from freebsd-database@pp.dyndns.biz) Received: from [192.168.69.69] ([192.168.69.69]) by keymaster.local (8.15.2/8.15.2) with ESMTP id xB2JIwpI078522 for ; Mon, 2 Dec 2019 20:18:59 +0100 (CET) (envelope-from freebsd-database@pp.dyndns.biz) Subject: Re: pf's states To: freebsd-pf@freebsd.org References: <20191202025642.GA99174@admin.sibptus.ru> <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> <20191202152543.GA16128@admin.sibptus.ru> From: =?UTF-8?Q?Morgan_Wesstr=c3=b6m?= Message-ID: Date: Mon, 2 Dec 2019 20:18:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191202152543.GA16128@admin.sibptus.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47RZfg6r5qz4F8q X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-database@pp.dyndns.biz has no SPF policy when checking 2a00:d880:5:1b9::8526) smtp.mailfrom=freebsd-database@pp.dyndns.biz X-Spamd-Result: default: False [1.72 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.72)[-0.717,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(-0.03)[asn: 198203(-0.18), country: NL(0.02)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_LONG(0.27)[0.272,0]; HFILTER_HELO_IP_A(1.00)[keymaster.local]; R_SPF_NA(0.00)[]; HFILTER_HELO_NORES_A_OR_MX(0.30)[keymaster.local]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:198203, ipnet:2a00:d880::/32, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_NA(0.00)[pp.dyndns.biz]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 02 Dec 2019 19:19:09 -0000 >>> =================================== >>> # DMZ 172.16.1.0/24 >>> pass in on $dmz >>> #block in on $dmz from any to 192.168.0.0/16 >>> >>> # Inside 192.168.10.0/24 >>> pass in on $inside >>> =================================== >>> >>> While the "block ..." line is commented out, I can "telnet 172.16.1.10 80" from 192.168.10.3. >> >> Rule 1 does not match this packet >> Rule 3 matches said packet, action is PASS The pass directive creates a state when only SYN is set out of SYN and ACK as per the manual page. It does NOT create a state when both SYN and ACK is set simultaneously as in your initial reply from the telnet server. Afaik a pass rule only creates state on the interface it monitors. I did not recreate your setup to check this though. But this is what should happen: With rule 2 remarked: - Your initial telnet SYN will create state on $inside through rule 3. - There should be no state created on $dmz. - Your SYN+ACK reply and further replies will be passed by pf's default pass behaviour on $dmz. With rule 2 active: - Your initial telnet SYN will create state on $inside through rule 3. - There should be no state created on $dmz. - Your SYN+ACK reply and further replies will be blocked by rule 2 since they match this rule and there are no states on $dmz to take precedence. My advice is to create ingoing and outgoing pass rules on both interfaces and to specify the state/flags combination even if they're the default. This way you will create states on both interfaces as you expect and additionally not run into nasty surprises if the default behaviour is changed in a future version of pf. pass in on $dmz flags S/SA keep state pass out on $dmz flags S/SA keep state pass in on $inside flags S/SA keep state pass out on $inside flags S/SA keep state /Morgan From owner-freebsd-pf@freebsd.org Tue Dec 3 03:49:06 2019 Return-Path: Delivered-To: freebsd-pf@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 595CF1C6481 for ; Tue, 3 Dec 2019 03:49:06 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47Rnz51wKZz3KMs for ; Tue, 3 Dec 2019 03:49:05 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=GVBMXNwxdKroLZhGOh+cYlIfXonXgg9hTE6UVcIA/Sg=; b=VrCdIWc07vyIaPvre8vbP94jxq 9NkvN90qfps9bmiQxTGXRab20RAGDiTTAw5HRhtM9CkpqrHrGHEnURhB6UHcKaF1uH2Q9soeZD9eF IzcuceZGIa92JCPfIwsyw23VaX0p1Iu/lyPu+IQ0oYl5XUqI5GhWdJX0GKXyLSLDdIHo=; Received: from vas by admin.sibptus.ru with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1ibzBP-00096D-DF for freebsd-pf@freebsd.org; Tue, 03 Dec 2019 10:49:03 +0700 Date: Tue, 3 Dec 2019 10:49:03 +0700 From: Victor Sudakov To: freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <20191203034903.GA33853@admin.sibptus.ru> References: <20191202025642.GA99174@admin.sibptus.ru> <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> <20191202152543.GA16128@admin.sibptus.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47Rnz51wKZz3KMs X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=VrCdIWc0; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-8.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.36)[ip: (-9.87), ipnet: 2001:19f0:5000::/38(-4.93), asn: 20473(-1.95), country: US(-0.05)]; DKIM_TRACE(0.00)[sibptus.ru:+]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Tue, 03 Dec 2019 03:49:06 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Morgan Wesstr=F6m wrote: > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> # DMZ 172.16.1.0/24 > >>> pass in on $dmz > >>> #block in on $dmz from any to 192.168.0.0/16 > >>> > >>> # Inside 192.168.10.0/24 > >>> pass in on $inside > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > >>> While the "block ..." line is commented out, I can "telnet 172.16.1.1= 0 80" from 192.168.10.3. > >> > >> Rule 1 does not match this packet > >> Rule 3 matches said packet, action is PASS >=20 > The pass directive creates a state when only SYN is set out of SYN and=20 > ACK as per the manual page. It does NOT create a state when both SYN and= =20 > ACK is set simultaneously as in your initial reply from the telnet=20 > server.=20 Do you mean to say that a state checks not only address:port pairs, but also TCP flags? This is a new notion for me. What would be a "pass" rule to create a "catch all" state with no regard for TCP flags? > Afaik a pass rule only creates state on the interface it=20 > monitors.=20 I'm afraid this is an incorrect assumption.=20 > I did not recreate your setup to check this though. But this=20 > is what should happen: >=20 > With rule 2 remarked: >=20 > - Your initial telnet SYN will create state on $inside through rule 3. > - There should be no state created on $dmz. I'm afraid this is an incorrect assumption. According to man pf.conf, by default "state-policy=3Dfloating" and state is not bound to interfaces. The output of "pfctl -s state" does not indicate any interfaces either, just protocols, addresses and ports. =20 --=20 Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJd5dsvAAoJEA2k8lmbXsY01QwH/3LLeE8i3+1A+dkThQgk+u+W ImFtVbJy/tS2WmT6tZMnm8KAPzRbIH6izkQAdYfmgjrezykh7mnRTL40H0GR8X+k I2H2EiTtYdMzDfaZyEIR+VXO3am1UZMr8vCHDjCSBU9qXgl9TqGSPczTE7ix+CuQ t7JM9Wziklb/w+vtw5MQpG9D05S2rZKlxe0FRcjF1vFt1cOU4XVxMcxBHEBgoGgs 8QNC8ZmcPvGBqXdKkCMesXCMlS8EUVYVsbjTYOMXPJZtpc7OMKTqrfY5lSapFNoZ +YF98jdYFvPvPdE73rZz2oMCvHLox4UaCDE20hgtk625RLmhlzNa5EAg+nyPoZI= =o0Vn -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From owner-freebsd-pf@freebsd.org Tue Dec 3 06:44:29 2019 Return-Path: Delivered-To: freebsd-pf@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 B13D61CA6AF for ; Tue, 3 Dec 2019 06:44:29 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47RssS3G4qz3y7r for ; Tue, 3 Dec 2019 06:44:28 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=QgOQ1RzacY7SFuonmyS7F5/bkT/kUuu5CIpMBZQCen0=; b=DzR5D7Q5vx6+DGGff+M8B78qJF q+I06BT22LKXuNkIt2Y8RR8ybwsw/FhigvT/pLdtDP5jGyD3Dm/H1UX3plt4ccuIy5ywEH/03TJV2 1IP0/HY4sSJi9+445EIr/mxp7g+XHgUMKEiypZiEiov+RVyY7PeV7IIAIbN2whl9S+yI=; Received: from vas by admin.sibptus.ru with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1ic1v9-0009vf-3n for freebsd-pf@freebsd.org; Tue, 03 Dec 2019 13:44:27 +0700 Date: Tue, 3 Dec 2019 13:44:27 +0700 From: Victor Sudakov To: freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <20191203064427.GA36581@admin.sibptus.ru> References: <20191202025642.GA99174@admin.sibptus.ru> <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47RssS3G4qz3y7r X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=DzR5D7Q5; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-8.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.36)[ip: (-9.87), ipnet: 2001:19f0:5000::/38(-4.93), asn: 20473(-1.96), country: US(-0.05)]; DKIM_TRACE(0.00)[sibptus.ru:+]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Tue, 03 Dec 2019 06:44:29 -0000 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Here is some output from the real lab (the hosts fw.test, inside.test and dmz.test are all FreeBSD VMs now). Any comments? Why does the state in the second case look so odd? root@fw:~ # cat /etc/rc.conf.local hostname=3D"fw.test" ifconfig_vtnet0=3D"DHCP description Outside" ifconfig_vtnet1=3D"172.16.1.1/24 description DMZ" ifconfig_vtnet2=3D"192.168.10.1/24 description Inside" pf_enable=3D"YES" gateway_enable=3D"YES" root@fw:~ # pfctl -s rules pass in on vtnet1 all flags S/SA keep state pass in on vtnet2 all flags S/SA keep state root@fw:~ # pfctl -s states all tcp 172.16.1.10:22 <- 192.168.10.3:41985 ESTABLISHED:ESTABLISHED root@fw:~ # root@inside:~ # telnet dmz.test 22 Trying 172.16.1.10... Connected to dmz.test. Escape character is '^]'. SSH-2.0-OpenSSH_7.5 FreeBSD-20170903 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D and here we enable the "bl= ock ..." rule =3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D root@fw:~ # pfctl -s rules pass in on vtnet1 all flags S/SA keep state block drop in on vtnet1 inet from any to 192.168.0.0/16 pass in on vtnet2 all flags S/SA keep state root@fw:~ # root@fw:~ # pfctl -s states all tcp 172.16.1.10:22 <- 192.168.10.3:50565 CLOSED:SYN_SENT root@fw:~ # root@inside:~ # telnet dmz.test 22 Trying 172.16.1.10... telnet: connect to address 172.16.1.10: Operation timed out telnet: Unable to connect to remote host --=20 Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJd5gRLAAoJEA2k8lmbXsY01wEH/RM9StGVwgg4nJChApPY63IE J6r13h0fL85uDE+oFM/5AQtkaX7PQa4Rqb6TMozV0eV60skFlvX0Fyzio3svurWj f/r2hQtgQKkgNdGv93qVxNuATKzmOM8RzF4l/cPu0sS+N5iOMXvmSNxQpObFyw5e HG8OFwMqpuJ8Zhrzir03JSch/wc0AVkDYkCAtAb7nJvu4A3pOB073Hv48g3PnRr4 1COanDOlJ9IsAwpL8hqZqOx6mkb9cl1bbN99ta5p+x+BlHaIu0bJ5iO3jyzH32dU ST1/hi9asUoZSH8AasGIMcLGzhjzkzh/D5F5eVGr5fQaszGLt52K1gF1dZV680E= =E2+n -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc-- From owner-freebsd-pf@freebsd.org Tue Dec 3 07:05:58 2019 Return-Path: Delivered-To: freebsd-pf@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 0F5241CAD50 for ; Tue, 3 Dec 2019 07:05:58 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47RtLF2VKqz403K for ; Tue, 3 Dec 2019 07:05:57 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=bHysHK9SboM2OAicyNJtTinL5ukFcGH5xxMRVHSzpdo=; b=o/x3U8J3MZ3DV0N2Jm2zSrcGqe szdfqJs0iWOrs0vjj1ZvjWeThT8dt8P3vFI6k1kl0ixtkCeqykU9TpwjtGP8dYnY5WjyO+3BB1c/Y 2qPrZFZ+WPIt0W2SlQgSpD5ABYdYxVXFhDPXkpD2iZtrNvL3O4COMgNdvDC2A60DFrCc=; Received: from vas by admin.sibptus.ru with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1ic2Fv-000A48-VW for freebsd-pf@freebsd.org; Tue, 03 Dec 2019 14:05:55 +0700 Date: Tue, 3 Dec 2019 14:05:55 +0700 From: Victor Sudakov To: freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <20191203070555.GA38510@admin.sibptus.ru> References: <20191202025642.GA99174@admin.sibptus.ru> <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> <20191202152543.GA16128@admin.sibptus.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47RtLF2VKqz403K X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=o/x3U8J3; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-8.47 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.37)[ip: (-9.87), ipnet: 2001:19f0:5000::/38(-4.94), asn: 20473(-1.97), country: US(-0.05)]; DKIM_TRACE(0.00)[sibptus.ru:+]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Tue, 03 Dec 2019 07:05:58 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Morgan Wesstr=F6m wrote: >=20 > - Your initial telnet SYN will create state on $inside through rule 3. > - There should be no state created on $dmz. > - Your SYN+ACK reply and further replies will be passed by pf's default= =20 > pass behaviour on $dmz. OK, let's forget about TCP flags entirely. Let's consider a simple ICMP pin= g. 1. Here is the picture without the "block..." rule: root@inside:~ # ping dmz.test PING dmz.test (172.16.1.10): 56 data bytes 64 bytes from 172.16.1.10: icmp_seq=3D0 ttl=3D63 time=3D0.532 ms 64 bytes from 172.16.1.10: icmp_seq=3D1 ttl=3D63 time=3D1.655 ms 64 bytes from 172.16.1.10: icmp_seq=3D2 ttl=3D63 time=3D1.682 ms 64 bytes from 172.16.1.10: icmp_seq=3D3 ttl=3D63 time=3D1.477 ms 64 bytes from 172.16.1.10: icmp_seq=3D4 ttl=3D63 time=3D1.626 ms root@fw:~ # pfctl -s rules ; echo ; pfctl -s state pass in on vtnet1 all flags S/SA keep state pass in on vtnet2 all flags S/SA keep state all icmp 172.16.1.10:1283 <- 192.168.10.3:1283 0:0 all icmp 192.168.10.3:1283 <- 172.16.1.10:1283 0:0 root@fw:~ # 2. Here is the picture with the "block..." rule uncommented: root@inside:~ # ping dmz.test PING dmz.test (172.16.1.10): 56 data bytes (no reply) root@fw:~ # pfctl -s rules ; echo ; pfctl -s state pass in on vtnet1 all flags S/SA keep state block drop in on vtnet1 inet from any to 192.168.0.0/16 pass in on vtnet2 all flags S/SA keep state all icmp 172.16.1.10:8707 <- 192.168.10.3:8707 0:0 root@fw:~ # --=20 Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJd5glTAAoJEA2k8lmbXsY0X74H/3bufYFR6FbPbgY78XLPEk0h db5gS4HYwpdi/RTCBEqrBSgoPFfjpV+R//rfX1XSd3vEsiDU+SNEsWVm4j/cNZPU zj28nOirfSH6Hv5J6ELRakKBEj/RGLn/JPWLPoS7lUqX7WMpK5HV878IOLWtniOV YWDtOZQqESMm743kfc2jwQ7GqtGS7hC+o1mdGkhIebluCHIB1hyvaOllmGTgZ0zh TTz4GzZ4VSY+n6RUxW0G9TUqWVh/DAk5LsLXFxnh52ZzFNm6yH/sRHyIELgwiZdB nlWe8ru6xqmD/mE3dKmq7xaRbHnQd5WaXiWl/HgxI9KcZLPZlQcudBxM+JMMYAw= =BxR5 -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-freebsd-pf@freebsd.org Tue Dec 3 08:51:53 2019 Return-Path: Delivered-To: freebsd-pf@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 B4C581CE0CE for ; Tue, 3 Dec 2019 08:51:53 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47RwhS4Sbbz46Nf for ; Tue, 3 Dec 2019 08:51:52 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C3A8B22601 for ; Tue, 3 Dec 2019 03:51:51 -0500 (EST) Received: from imap6 ([10.202.2.56]) by compute7.internal (MEProxy); Tue, 03 Dec 2019 03:51:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=nazWw JsZduHtjjo1WhtMi0pNY6IaI0tX2lm9M4hicVk=; b=APtPPHc6kXJq1GmwdWszl xN7MosfCzLL3BPPH2wNOhyLnkHRtc8ZPrWqNYSh0EKtkW7k+bFqCEuvcUQJ3rUI4 H4ZqB7bDzRKip6kYGDbQUHcu+vCvyfDyN47zW7T+KdXgIWe1mddXSr5Q7B156WXW vVQN66Mz+3RPUQQYVc0vJ0sQHJpVmEbOGWr7qPfBKod0a1vBfYXalb53mrodGZYB wNl8ZTnrUUx8sFwpG/sa5pNwDPkgjD+SJ5+Z1v7YQ+fl4w6tEGCB64Xz2m5fSNcR D6rSS0ZChSpbnpViaieenm20qC3cMZjN+0UWwX5VDQGUsM1ktDarsOMVULFNedrc Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=nazWwJsZduHtjjo1WhtMi0pNY6IaI0tX2lm9M4hic Vk=; b=Ytvwqija9p242dV8kY7Nx4Ji9V0AQCxvMBhxn7o+uw+MapHuNJuca9Ncv EsrSqZ1+vAryhHqP30ZGTWmmvMHTSR3ln2iWIfzhQe0GmYQSOz/p20Hc+/VrDYlk ilEd7BCn8y60+I7oahXCDs7Sr91dkZA9cqVETUUZDMXTsJA8yxvJVeMDGwJvTDIV 85AQwIe9phE35zqavgZDgVBwIk9uzDXnmitkNhBlQrdgFZ0TYFHTKp3ziDdW4M9J Ia/evPrhPm9MMlF+io7jBlifXqw8QXADyxfi6OrYy5KBVUo+VFR2fL2bNwjqCumr JaC25LOcml0aIzL+uMPAHQWLeYXlQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudejiedguddvudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedfffgrvhgvucevohhtthhlvghhuhgsvghrfdcuoegu tghhsehskhhunhhkfigvrhhkshdrrghtqeenucffohhmrghinhepvhgrshdrthhomhhskh drrhhupdhskhhunhhkfigvrhhkshdrrghtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu tghhsehskhhunhhkfigvrhhkshdrrghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 796A31400A2; Tue, 3 Dec 2019 03:51:51 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-612-g13027cc-fmstable-20191203v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <20191203070555.GA38510@admin.sibptus.ru> References: <20191202025642.GA99174@admin.sibptus.ru> <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> <20191202152543.GA16128@admin.sibptus.ru> <20191203070555.GA38510@admin.sibptus.ru> Date: Tue, 03 Dec 2019 09:51:30 +0100 From: "Dave Cottlehuber" To: freebsd-pf Subject: Re: pf's states Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 47RwhS4Sbbz46Nf X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skunkwerks.at header.s=fm1 header.b=APtPPHc6; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=Ytvwqija; dmarc=none; spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 66.111.4.25 as permitted sender) smtp.mailfrom=dch@skunkwerks.at X-Spamd-Result: default: False [-5.07 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm1,messagingengine.com:s=fm1]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[25.4.111.66.rep.mailspike.net : 127.0.0.18]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; DMARC_NA(0.00)[skunkwerks.at]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-3.48)[ip: (-9.78), ipnet: 66.111.4.0/24(-4.87), asn: 11403(-2.68), country: US(-0.05)]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[25.4.111.66.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Tue, 03 Dec 2019 08:51:53 -0000 TLDR add log to the rules, then start pflog,use wireshark or tcpdump on = the pflog interface and you can see exactly which rule is applied to tha= t packet. On Tue, 3 Dec 2019, at 08:05, Victor Sudakov wrote: > Morgan Wesstr=C3=B6m wrote: > >=20 > > - Your initial telnet SYN will create state on $inside through rule = 3. > > - There should be no state created on $dmz. > > - Your SYN+ACK reply and further replies will be passed by pf's defa= ult=20 > > pass behaviour on $dmz. >=20 > OK, let's forget about TCP flags entirely. Let's consider a simple ICM= P ping. >=20 > 1. Here is the picture without the "block..." rule: >=20 > root@inside:~ # ping dmz.test > PING dmz.test (172.16.1.10): 56 data bytes > 64 bytes from 172.16.1.10: icmp_seq=3D0 ttl=3D63 time=3D0.532 ms > 64 bytes from 172.16.1.10: icmp_seq=3D1 ttl=3D63 time=3D1.655 ms > 64 bytes from 172.16.1.10: icmp_seq=3D2 ttl=3D63 time=3D1.682 ms > 64 bytes from 172.16.1.10: icmp_seq=3D3 ttl=3D63 time=3D1.477 ms > 64 bytes from 172.16.1.10: icmp_seq=3D4 ttl=3D63 time=3D1.626 ms >=20 > root@fw:~ # pfctl -s rules ; echo ; pfctl -s state > pass in on vtnet1 all flags S/SA keep state > pass in on vtnet2 all flags S/SA keep state >=20 > all icmp 172.16.1.10:1283 <- 192.168.10.3:1283 0:0 > all icmp 192.168.10.3:1283 <- 172.16.1.10:1283 0:0 > root@fw:~ # >=20 > 2. Here is the picture with the "block..." rule uncommented: >=20 > root@inside:~ # ping dmz.test > PING dmz.test (172.16.1.10): 56 data bytes > (no reply) >=20 > root@fw:~ # pfctl -s rules ; echo ; pfctl -s state > pass in on vtnet1 all flags S/SA keep state > block drop in on vtnet1 inet from any to 192.168.0.0/16 > pass in on vtnet2 all flags S/SA keep state >=20 > all icmp 172.16.1.10:8707 <- 192.168.10.3:8707 0:0 > root@fw:~ # >=20 >=20 >=20 >=20 > --=20 > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > 2:5005/49@fidonet http://vas.tomsk.ru/ >=20 > Attachments: > * signature.asc --=20 =E2=80=94 Dave Cottlehuber +43 67 67 22 44 78 Managing Director Skunkwerks, GmbH http://skunkwerks.at/ ATU70126204 Firmenbuch 410811i From owner-freebsd-pf@freebsd.org Tue Dec 3 09:15:14 2019 Return-Path: Delivered-To: freebsd-pf@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 CA8301CEEA5 for ; Tue, 3 Dec 2019 09:15:14 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47RxCQ1200z4825 for ; Tue, 3 Dec 2019 09:15:13 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=PkP3mVzc9ogE7h6X2aTuKr3vF3XrXqyVptE8prm2epM=; b=df3MD2qsOEHy8LmKti9fw+/8zl VdWTMysGu9kGOUd5ZcYZTKEnXla5usbDQOfBXXFsr3N/oSq+StI5ZoKw7Boii27ISIhRLHJNAk5Ke oBHTuO1S16Wcg8NL1fR2dI2aLl5Zvw4rbDkvciz9ITvvek4Shmu9fVTQseqIYZISZQvU=; Received: from vas by admin.sibptus.ru with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1ic4H2-000AnP-SZ for freebsd-pf@freebsd.org; Tue, 03 Dec 2019 16:15:12 +0700 Date: Tue, 3 Dec 2019 16:15:12 +0700 From: Victor Sudakov To: freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <20191203091512.GD40372@admin.sibptus.ru> References: <20191202025642.GA99174@admin.sibptus.ru> <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> <20191202152543.GA16128@admin.sibptus.ru> <20191203070555.GA38510@admin.sibptus.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tNQTSEo8WG/FKZ8E" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47RxCQ1200z4825 X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=df3MD2qs; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-8.47 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.37)[ip: (-9.87), ipnet: 2001:19f0:5000::/38(-4.94), asn: 20473(-2.00), country: US(-0.05)]; DKIM_TRACE(0.00)[sibptus.ru:+]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Tue, 03 Dec 2019 09:15:14 -0000 --tNQTSEo8WG/FKZ8E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dave Cottlehuber wrote: > TLDR add log to the rules, then start pflog,use wireshark or tcpdump > on the pflog interface and you can see exactly which rule is applied > to that packet. It's not that the wrong rules are being applied, there are 2-3 rules in total in the whole lab, they are easy to monitor with rule counters. It's the state being created from the rules that confuses me. And the state if visible in "pfctl -s states". The problem is that either I'm confused about how pf state works, or the documentation is misleading/incomplete. --=20 Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ --tNQTSEo8WG/FKZ8E Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJd5iegAAoJEA2k8lmbXsY0wMYH/RSRrC4Dj+EOa/DVE+hTSANT v85+tmHQ+p0MX40NctAHKHXrg2EbC06cCts880xmnO5v2CF0wkw6frWstf8iOGP7 XgZXtWkjXBOeKWISNHLFCW2S7JSvnNAH9EuaGYgLNu1D9KTkBgX+VL+8EL+EBFna TG68w4rexuSf+r4Ufj+X1fMMiyOeKGMwCcImNyABUoVikIn4KhpCKAWvqsu26zZw zykbtOeDltM04WEN/t1usC9QMeWYm0JftgtNSZ3VcJq52vrwFL0jVmwPOXzZBA51 nF6ZPTxEh5MtWf9Qy8djsDtVDb4UoPfCl7DmUgSqTOcFhvVuhJZxED+DEJPUmgI= =7Wed -----END PGP SIGNATURE----- --tNQTSEo8WG/FKZ8E-- From owner-freebsd-pf@freebsd.org Tue Dec 3 09:26:14 2019 Return-Path: Delivered-To: freebsd-pf@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 6092E1CF27C for ; Tue, 3 Dec 2019 09:26:14 +0000 (UTC) (envelope-from freebsd-database@pp.dyndns.biz) Received: from keymaster.local (ns1.xn--wesstrm-f1a.se [IPv6:2a00:d880:5:1b9::8526]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "keymaster.pp.dyndns.biz", Issuer "keymaster.pp.dyndns.biz" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RxS50sCPz48V5 for ; Tue, 3 Dec 2019 09:26:12 +0000 (UTC) (envelope-from freebsd-database@pp.dyndns.biz) Received: from [192.168.69.69] ([192.168.69.69]) by keymaster.local (8.15.2/8.15.2) with ESMTP id xB39Q9Pp001317 for ; Tue, 3 Dec 2019 10:26:10 +0100 (CET) (envelope-from freebsd-database@pp.dyndns.biz) Subject: Re: pf's states To: freebsd-pf@freebsd.org References: <20191202025642.GA99174@admin.sibptus.ru> <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> <20191202152543.GA16128@admin.sibptus.ru> <20191203034903.GA33853@admin.sibptus.ru> From: =?UTF-8?Q?Morgan_Wesstr=c3=b6m?= Message-ID: Date: Tue, 3 Dec 2019 10:26:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191203034903.GA33853@admin.sibptus.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47RxS50sCPz48V5 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-database@pp.dyndns.biz has no SPF policy when checking 2a00:d880:5:1b9::8526) smtp.mailfrom=freebsd-database@pp.dyndns.biz X-Spamd-Result: default: False [1.47 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.74)[-0.736,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(-0.03)[asn: 198203(-0.18), country: NL(0.02)]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_LONG(0.03)[0.033,0]; HFILTER_HELO_IP_A(1.00)[keymaster.local]; R_SPF_NA(0.00)[]; HFILTER_HELO_NORES_A_OR_MX(0.30)[keymaster.local]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:198203, ipnet:2a00:d880::/32, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_NA(0.00)[pp.dyndns.biz]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Tue, 03 Dec 2019 09:26:14 -0000 > Do you mean to say that a state checks not only address:port pairs, but > also TCP flags? This is a new notion for me. What would be a "pass" rule > to create a "catch all" state with no regard for TCP flags? For TCP it checks the flags when the state is created. From man pf.conf flags / | / | any This rule only applies to TCP packets that have the flags set out of set . Flags not specified in are ignored. For stateful connections, the default is flags S/SA. To indicate that flags should not be checked at all, specify flags any. The flags are: (F)IN, (S)YN, (R)ST, (P)USH, (A)CK, (U)RG, (E)CE, and C(W)R. > >> Afaik a pass rule only creates state on the interface it >> monitors. > > I'm afraid this is an incorrect assumption. > >> I did not recreate your setup to check this though. But this >> is what should happen: >> >> With rule 2 remarked: >> >> - Your initial telnet SYN will create state on $inside through rule 3. >> - There should be no state created on $dmz. > > I'm afraid this is an incorrect assumption. According to man pf.conf, by > default "state-policy=floating" and state is not bound to interfaces. > The output of "pfctl -s state" does not indicate any interfaces either, > just protocols, addresses and ports. > This is weird. My state tables clearly shows the interface name first on the line instead of "all" but I use state-policy if-bound. I have no experience with floating mode, thus my assumptions earlier. I apologize if I was wrong. /Morgan From owner-freebsd-pf@freebsd.org Tue Dec 3 09:49:13 2019 Return-Path: Delivered-To: freebsd-pf@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 B2CE31CFA83 for ; Tue, 3 Dec 2019 09:49:13 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47Rxyd1Gwzz49cq for ; Tue, 3 Dec 2019 09:49:13 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=XYQLejIoFFfFIeFpX1FALMj5TqGvzNpR09Ev6cWAXLw=; b=Py8rSXfi8K4FtJ6y9oy3IRpclH AqToHvqiiFvaqX+PJ3VDjtZRqjI82YhqJVgxRSrT6e0cHFaH+CbbgBvZTppnLKx55R5MgaqQe92uX CbiZuFyfCguWfR5kEBhBkUBqV4AUnANI0bP3YOUw75T+bpxTLcT1nGgfHkTXneUZ8PSo=; Received: from vas by admin.sibptus.ru with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1ic4nv-000B3i-KE for freebsd-pf@freebsd.org; Tue, 03 Dec 2019 16:49:11 +0700 Date: Tue, 3 Dec 2019 16:49:11 +0700 From: Victor Sudakov To: freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <20191203094911.GF40372@admin.sibptus.ru> References: <20191202025642.GA99174@admin.sibptus.ru> <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> <20191202152543.GA16128@admin.sibptus.ru> <20191203034903.GA33853@admin.sibptus.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fwqqG+mf3f7vyBCB" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47Rxyd1Gwzz49cq X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=Py8rSXfi; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-8.47 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.37)[ip: (-9.87), ipnet: 2001:19f0:5000::/38(-4.94), asn: 20473(-2.01), country: US(-0.05)]; DKIM_TRACE(0.00)[sibptus.ru:+]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Tue, 03 Dec 2019 09:49:13 -0000 --fwqqG+mf3f7vyBCB Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Morgan Wesstr=F6m wrote: > > Do you mean to say that a state checks not only address:port pairs, but > > also TCP flags? This is a new notion for me. What would be a "pass" rule > > to create a "catch all" state with no regard for TCP flags? >=20 > For TCP it checks the flags when the state is created. From man pf.conf Forget TCP for now, let's explain the ICMP ping case I posted earlier. [dd] > > I'm afraid this is an incorrect assumption. According to man pf.conf, by > > default "state-policy=3Dfloating" and state is not bound to interfaces. > > The output of "pfctl -s state" does not indicate any interfaces either, > > just protocols, addresses and ports. > >=20 >=20 > This is weird. My state tables clearly shows the interface name first on= =20 > the line instead of "all" but I use state-policy if-bound. I have no=20 > experience with floating mode, thus my assumptions earlier. I apologize= =20 > if I was wrong. You need not apologize, my lab runs a very basic pf configuration where state-policy=3Dfloating by default. --=20 Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ --fwqqG+mf3f7vyBCB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJd5i+XAAoJEA2k8lmbXsY08UcIAKL+1MJygcnbLik75fAwKl9B A1bk/xIXf89HJcDYGYgTia7Jz3caAVAJA20xzHVivuZRKLPczxNtKlqrPnRpTEi/ sttdywqck5m3NVafdEYZ2wasX+JaVrvDrn9MDvd2Z09s3QA8NgnuYVRB2sjWXrwf TQZ3d9rHw7fZdjz0ILdJbt90ARnlAHDD0gKXbKmWcor2+bOCdlMCIqAlYGcYI0xv Mno1YBUFWhR7qzYGTs1gSYVi2U2iwOYSzCwPau5zuJZS7hyOWgKGhYKBtX362BPf WZl+OvvI+FxGxAai68r2BeMfsOiRftxhBPsa5lMqfoCcnMkXTOVm9i3HhlqlNvA= =fJDX -----END PGP SIGNATURE----- --fwqqG+mf3f7vyBCB-- From owner-freebsd-pf@freebsd.org Tue Dec 3 19:26:07 2019 Return-Path: Delivered-To: freebsd-pf@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 CF8D01BAEA8 for ; Tue, 3 Dec 2019 19:26:07 +0000 (UTC) (envelope-from artem@viklenko.net) Received: from alf.viklenko.net (alf.viklenko.net [IPv6:2001:470:71:d72::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.viklenko.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47SBmG12w5z3MYv for ; Tue, 3 Dec 2019 19:26:05 +0000 (UTC) (envelope-from artem@viklenko.net) Received: from [IPv6:2001:470:71:d72:1208:b1ff:fe93:6f45] ([IPv6:2001:470:71:d72:1208:b1ff:fe93:6f45]) (authenticated bits=0) by alf.viklenko.net (8.15.2/8.15.2) with ESMTPSA id xB3JPsHq035917 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 3 Dec 2019 21:25:58 +0200 (EET) (envelope-from artem@viklenko.net) Subject: Re: pf's states To: freebsd-pf@freebsd.org References: <20191202025642.GA99174@admin.sibptus.ru> <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> <20191202152543.GA16128@admin.sibptus.ru> <20191203034903.GA33853@admin.sibptus.ru> <20191203094911.GF40372@admin.sibptus.ru> From: Artem Viklenko Message-ID: Date: Tue, 3 Dec 2019 21:25:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191203094911.GF40372@admin.sibptus.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Language: uk-UA Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (alf.viklenko.net [IPv6:2001:470:71:d72:0:0:0:61]); Tue, 03 Dec 2019 21:25:58 +0200 (EET) X-Rspamd-Queue-Id: 47SBmG12w5z3MYv X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.64 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[viklenko.net:s=alf-mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DKIM_TRACE(0.00)[viklenko.net:+]; DMARC_POLICY_ALLOW(-0.50)[viklenko.net,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.64)[ipnet: 2001:470::/32(-4.64), asn: 6939(-3.53), country: US(-0.05)]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Tue, 03 Dec 2019 19:26:07 -0000 Had to build test lab.... I still not 100% sure about state-policy - can't check it now. But it definitelly can influence on the final result. First of all check output of pfctl -vvsr - it will show full ruleset. Next - after sending traffic - check pfctl -vvss - it will show exact states and by which rule it was created. Third - use tcpdump on pflog0 interface to see logs but you need rules with log keyword for this. In short - as you don't use quick keyword - the last rule wins as Max already noted. Simple ruleset: block drop log inet all label "BLOCK-ALL" pass inet proto icmp from 192.168.32.0/26 to 192.168.34.0/26 keep state pass inet proto tcp from 192.168.32.0/26 to 192.168.34.0/26 flags S/SA keep state # pfctl -vvsr @0 block drop log inet all label "BLOCK-ALL" [ Evaluations: 19 Packets: 17 Bytes: 1301 States: 0 ] [ Inserted: uid 0 pid 1242 State Creations: 0 ] @1 pass inet proto icmp from 192.168.32.0/26 to 192.168.34.0/26 keep state [ Evaluations: 19 Packets: 68 Bytes: 5712 States: 2 ] [ Inserted: uid 0 pid 1242 State Creations: 2 ] @2 pass inet proto tcp from 192.168.32.0/26 to 192.168.34.0/26 flags S/SA keep state [ Evaluations: 19 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 1242 State Creations: 0 ] Ping from 192.168.32.9 to 192.168.34.2 produce two states: # pfctl -vvss all icmp 192.168.34.2:8 <- 192.168.32.9:8 0:0 age 00:00:20, expires in 00:00:10, 20:20 pkts, 1680:1680 bytes, rule 1 id: 000000005de6aaaa creatorid: 60d9c3f7 all icmp 192.168.32.9:8 -> 192.168.34.2:8 0:0 age 00:00:20, expires in 00:00:10, 20:20 pkts, 1680:1680 bytes, rule 1 id: 000000005de6aaab creatorid: 60d9c3f7 One for each action - receive via one interface and transmit via another. As state-policy is folating - no interface names was shown. Traffic coming in the system was inspected by pf rules and first state was created. Then traffic going out to destination via another interface was inspected by pf again and second state was created by the same rule #1. ICMP replies going in reverse direction pass due to these states. Now while host 192.168.32.9 continues to ping 192.168.34.2 and states active, I've added another rule: block drop inet proto icmp from 192.168.34.2 to 192.168.32.9 # pfctl -vvsr @0 block drop log inet all label "BLOCK-ALL" [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 1330 State Creations: 0 ] @1 pass inet proto icmp from 192.168.32.0/26 to 192.168.34.0/26 keep state [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 1330 State Creations: 0 ] @2 pass inet proto tcp from 192.168.32.0/26 to 192.168.34.0/26 flags S/SA keep state [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 1330 State Creations: 0 ] @3 block drop inet proto icmp from 192.168.34.2 to 192.168.32.9 [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 1330 State Creations: 0 ] But already established states allows traffic to pass # pfctl -vvss all icmp 192.168.34.2:9 <- 192.168.32.9:9 0:0 age 00:02:46, expires in 00:00:10, 163:163 pkts, 13692:13692 bytes, rule 1 id: 000000005de6aaac creatorid: 60d9c3f7 all icmp 192.168.32.9:9 -> 192.168.34.2:9 0:0 age 00:02:46, expires in 00:00:10, 163:163 pkts, 13692:13692 bytes, rule 1 id: 000000005de6aaad creatorid: 60d9c3f7 # pfctl -vvss all icmp 192.168.34.2:9 <- 192.168.32.9:9 0:0 age 00:02:47, expires in 00:00:10, 164:164 pkts, 13776:13776 bytes, rule 1 id: 000000005de6aaac creatorid: 60d9c3f7 all icmp 192.168.32.9:9 -> 192.168.34.2:9 0:0 age 00:02:47, expires in 00:00:10, 164:164 pkts, 13776:13776 bytes, rule 1 id: 000000005de6aaad creatorid: 60d9c3f7 Now stop ping and let states to expire. Start ping again and... it still successfull. # pfctl -vvss all icmp 192.168.34.2:10 <- 192.168.32.9:10 0:0 age 00:00:06, expires in 00:00:10, 7:7 pkts, 588:588 bytes, rule 1 id: 000000005de6aaae creatorid: 8908ecf5 all icmp 192.168.32.9:10 -> 192.168.34.2:10 0:0 age 00:00:06, expires in 00:00:10, 7:7 pkts, 588:588 bytes, rule 1 id: 000000005de6aaaf creatorid: 8908ecf5 Because states was again created by rule #1. A bit changed ruleset (in keyword added): # pfctl -vvsr @0 block drop log inet all label "BLOCK-ALL" [ Evaluations: 21 Packets: 20 Bytes: 1680 States: 0 ] [ Inserted: uid 0 pid 1458 State Creations: 0 ] @1 pass in inet proto icmp from 192.168.32.0/26 to 192.168.34.0/26 keep state [ Evaluations: 21 Packets: 40 Bytes: 2800 States: 0 ] [ Inserted: uid 0 pid 1458 State Creations: 1 ] @2 pass in inet proto tcp from 192.168.32.0/26 to 192.168.34.0/26 flags S/SA keep state [ Evaluations: 1 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 1458 State Creations: 0 ] @3 block drop in inet proto icmp from 192.168.34.2 to 192.168.32.9 [ Evaluations: 1 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 1458 State Creations: 0 ] lead to: PING 192.168.34.2 (192.168.34.2) 56(84) bytes of data. From 192.168.32.1 icmp_seq=1 Destination Host Unreachable From 192.168.32.1 icmp_seq=2 Destination Host Unreachable From 192.168.32.1 icmp_seq=3 Destination Host Unreachable only one state: # pfctl -vvss all icmp 192.168.34.2:14 <- 192.168.32.9:14 0:0 age 00:00:02, expires in 00:00:10, 3:3 pkts, 252:168 bytes, rule 1 id: 000000005de6aab7 creatorid: 9dc6ab26 and: # tcpdump -fnet -s0 -p -i pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 65535 bytes rule 0..16777216/0(match): block out on fxp1: 192.168.32.9 > 192.168.34.2: ICMP echo request, id 14, seq 15, length 64 rule 0..16777216/0(match): block out on fxp1: 192.168.32.9 > 192.168.34.2: ICMP echo request, id 14, seq 16, length 64 Rule #0 blocked traffic while firewall tried to forward packet and transmit it via fxp1 interface. Again changing ruleset: # pfctl -vvsr @0 pass in inet proto icmp from 192.168.32.0/26 to 192.168.34.0/26 keep state [ Evaluations: 44 Packets: 17 Bytes: 1428 States: 0 ] [ Inserted: uid 0 pid 1533 State Creations: 1 ] @1 pass in inet proto tcp from 192.168.32.0/26 to 192.168.34.0/26 flags S/SA keep state [ Evaluations: 6 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 1533 State Creations: 0 ] @2 block drop in log inet proto icmp from 192.168.34.2 to 192.168.32.9 [ Evaluations: 23 Packets: 17 Bytes: 1428 States: 0 ] [ Inserted: uid 0 pid 1533 State Creations: 0 ] start to ping... no response: PING 192.168.34.2 (192.168.34.2) 56(84) bytes of data. ^C --- 192.168.34.2 ping statistics --- 17 packets transmitted, 0 received, 100% packet loss, time 16209ms # tcpdump -fnet -s0 -p -i pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 65535 bytes rule 2..16777216/0(match): block in on fxp1: 192.168.34.2 > 192.168.32.9: ICMP echo reply, id 16, seq 8, length 64 rule 2..16777216/0(match): block in on fxp1: 192.168.34.2 > 192.168.32.9: ICMP echo reply, id 16, seq 9, length 64 ^C 2 packets captured 3 packets received by filter 0 packets dropped by kernel only one state: # pfctl -vvss all icmp 192.168.34.2:16 <- 192.168.32.9:16 0:0 age 00:00:13, expires in 00:00:09, 13:0 pkts, 1092:0 bytes, rule 0 id: 000000005de6aab9 creatorid: 4ac4eac6 while traffic leaves firewall, reaches destination and it replies: # tcpdump -fnet -s 0 -p -i fxp1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on fxp1, link-type EN10MB (Ethernet), capture size 65535 bytes 00:17:65:f5:ed:f1 > 00:16:d4:bf:71:45, ethertype IPv4 (0x0800), length 98: 192.168.32.9 > 192.168.34.2: ICMP echo request, id 17, seq 1, length 64 00:16:d4:bf:71:45 > 00:17:65:f5:ed:f1, ethertype IPv4 (0x0800), length 98: 192.168.34.2 > 192.168.32.9: ICMP echo reply, id 17, s eq 1, length 64 00:17:65:f5:ed:f1 > 00:16:d4:bf:71:45, ethertype IPv4 (0x0800), length 98: 192.168.32.9 > 192.168.34.2: ICMP echo request, id 17, seq 2, length 64 00:16:d4:bf:71:45 > 00:17:65:f5:ed:f1, ethertype IPv4 (0x0800), length 98: 192.168.34.2 > 192.168.32.9: ICMP echo reply, id 17, s eq 2, length 64 This is because by default pf allows traffic but not create states. You can start pf with empty ruleset and see no states while traffic passing firewall. So then traffic came back it was blocked by last matched rule with keyword in which is rule #2 in this case. To summarise: You should carefully build ruleset and check what is going on with traffic all the way. Use log keyword to send data to pflog interface where it can be checked. pfctl -vvsr, pfctl -vvss showes which state was created by whic rule. That's all! 03.12.19 11:49, Victor Sudakov пише: > Morgan Wesström wrote: >>> Do you mean to say that a state checks not only address:port pairs, but >>> also TCP flags? This is a new notion for me. What would be a "pass" rule >>> to create a "catch all" state with no regard for TCP flags? >> >> For TCP it checks the flags when the state is created. From man pf.conf > > Forget TCP for now, let's explain the ICMP ping case I posted earlier. > > [dd] > >>> I'm afraid this is an incorrect assumption. According to man pf.conf, by >>> default "state-policy=floating" and state is not bound to interfaces. >>> The output of "pfctl -s state" does not indicate any interfaces either, >>> just protocols, addresses and ports. >>> >> >> This is weird. My state tables clearly shows the interface name first on >> the line instead of "all" but I use state-policy if-bound. I have no >> experience with floating mode, thus my assumptions earlier. I apologize >> if I was wrong. > > You need not apologize, my lab runs a very basic pf configuration where > state-policy=floating by default. > -- Regards! From owner-freebsd-pf@freebsd.org Wed Dec 4 07:47:11 2019 Return-Path: Delivered-To: freebsd-pf@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 C46D01CC3B7 for ; Wed, 4 Dec 2019 07:47:11 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47SWCL64FFz4X2c for ; Wed, 4 Dec 2019 07:47:10 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=FpEGBiCoomcDTLPwEelevQ6LLdj1YUFAvZ8W3HjG/YA=; b=X8OI9ywtE3ActGpOJpYsi9g17+ MqTjeBeJ4raUCoJM7EXdEUlfbTDGP1jtriWAdOEcNqAGWpL1mJtv/79d0EOIWPxG+b1046GrRTqfQ 6TgzPXgC5gzQUQBA9/nUCbw2qcfVvjudRlJQvOBQRh0TBblGUm+XlhQpmrnqlJbz7Gzg=; Received: from vas by admin.sibptus.ru with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1icPNH-000N53-1M for freebsd-pf@freebsd.org; Wed, 04 Dec 2019 14:47:03 +0700 Date: Wed, 4 Dec 2019 14:47:03 +0700 From: Victor Sudakov To: freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <20191204074703.GA88680@admin.sibptus.ru> References: <20191202025642.GA99174@admin.sibptus.ru> <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> <20191202152543.GA16128@admin.sibptus.ru> <20191203034903.GA33853@admin.sibptus.ru> <20191203094911.GF40372@admin.sibptus.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47SWCL64FFz4X2c X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=X8OI9ywt; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-8.48 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.38)[ip: (-9.87), ipnet: 2001:19f0:5000::/38(-4.94), asn: 20473(-2.03), country: US(-0.05)]; DKIM_TRACE(0.00)[sibptus.ru:+]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Wed, 04 Dec 2019 07:47:11 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Artem Viklenko via freebsd-pf wrote: > Had to build test lab.... Thank you for your time. >=20 > I still not 100% sure about state-policy - can't check it now. > But it definitelly can influence on the final result. Let's stick to the default floating state-policy for now. No need to make the lab more complicated. >=20 > Simple ruleset: Once you have invested your time to build the lab, could you please reproduce my ruleset exactly (I'll repeat it below)? Unlike yours, my ruleset has *all* rules bound to interfaces. It would be also very nice of you to use the same IP addresses so that we did not have to translate the addresses mentally. [dd] >=20 > Traffic coming in the system was inspected by pf > rules and first state was created. Then traffic going out to destination > via another interface was inspected by pf again and second state was=20 > created by the same rule #1. >=20 > ICMP replies going in reverse direction pass due to these states. Why would you need two states to pass the replies, that is the question. If the rule is floating, why is one rule not enough? [dd] >=20 > This is because by default pf allows traffic but not create states. > You can start pf with empty ruleset and see no states while traffic > passing firewall. No doubt about it. But I was not talking about the complete absense of states. Please see below. >=20 > So then traffic came back it was blocked by last matched rule with > keyword in which is rule #2 in this case. No, in my case *one* state is being created. The question is why this one available state is not enough to pass return traffic? Please peruse the pfc= tl output I provide below: A brief repetition of what I was doing. I'd be grateful if you replicate it. 1. Interface configuration hostname=3D"fw.test" ifconfig_vtnet0=3D"DHCP description Outside" ifconfig_vtnet1=3D"172.16.1.1/24 description DMZ" ifconfig_vtnet2=3D"192.168.10.1/24 description Inside" 2. Ping configuration Pinging 172.16.1.10 (dmz host) from 192.168.10.3 (inside host). 3. Rules root@fw:~ # pfctl -vvs rules No ALTQ support in kernel ALTQ related functions disabled @0 pass in on vtnet1 all flags S/SA keep state [ Evaluations: 9596 Packets: 1 Bytes: 84 States: 0 = ] [ Inserted: uid 0 pid 1343 State Creations: 1 ] @1 block drop in on vtnet1 inet from any to 192.168.0.0/16 [ Evaluations: 2955 Packets: 2954 Bytes: 248136 States: 0 = ] [ Inserted: uid 0 pid 1343 State Creations: 0 ] @2 pass in on vtnet2 all flags S/SA keep state [ Evaluations: 6641 Packets: 2955 Bytes: 248220 States: 1 = ] [ Inserted: uid 0 pid 1343 State Creations: 2 ] root@fw:~ # 4. State while pinging: root@fw:~ # pfctl -vvs states No ALTQ support in kernel ALTQ related functions disabled all icmp 172.16.1.10:33794 <- 192.168.10.3:33794 0:0 age 00:51:57, expires in 00:00:10, 2970:0 pkts, 249480:0 bytes, rule 2 id: 000000005de756c8 creatorid: 9da41898 root@fw:~ # 5. Question: We see that a floating state "172.16.1.10:33794 <- 192.168.10.3:33794" has = been created by rule 2. Why is this state not passing ICMP replies from 172.16.1= =2E10 to 192.168.10.3 ? I.e. why is this state not overriding the blocking rule 1 ? --=20 Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJd52R3AAoJEA2k8lmbXsY0fikIAJYtdQ4ms9Nhgqh2ZOTS8UTo jmDGIxCZa2JWKSoQNj88/b6iRngLJKhn6BORRQdeO/nE5gL3y7yYnIiFXacM1PR8 vmB8fpCOM59jz9Adsx8KfYhhrLAjEdlZhYRJ2N0/sgNp5eCWCrGZyhH18e8egWXe 6TR/fhUqClt4ij2wanCbRLhoqCzj3CcR3DsCXxgpjyuAK5BLPRmQlFvJvO4LEMj9 AMQpuXgfqEG796T5Yr3RnC7aZRVhASdEmZo4dVGO2rQLmj3cr2H/Q/KQz0xbz4uG t4mRqpwRMDo1yQKGNzaZ0t+OMpwpzLSVI3e00tTtY608TjsdhY272mS/hvBXZ6M= =dzIT -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From owner-freebsd-pf@freebsd.org Wed Dec 4 08:55:24 2019 Return-Path: Delivered-To: freebsd-pf@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 8989C1CE05A for ; Wed, 4 Dec 2019 08:55:24 +0000 (UTC) (envelope-from artem@viklenko.net) Received: from alf.viklenko.net (alf.viklenko.net [IPv6:2001:470:71:d72::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.viklenko.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47SXk329K3z4bQv for ; Wed, 4 Dec 2019 08:55:22 +0000 (UTC) (envelope-from artem@viklenko.net) Received: from [10.0.31.12] (ua1.etadirect.net [91.198.140.16] (may be forged)) (authenticated bits=0) by alf.viklenko.net (8.15.2/8.15.2) with ESMTPSA id xB48tFkX007421 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Dec 2019 10:55:20 +0200 (EET) (envelope-from artem@viklenko.net) Subject: Re: pf's states To: freebsd-pf@freebsd.org References: <20191202025642.GA99174@admin.sibptus.ru> <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> <20191202152543.GA16128@admin.sibptus.ru> <20191203034903.GA33853@admin.sibptus.ru> <20191203094911.GF40372@admin.sibptus.ru> <20191204074703.GA88680@admin.sibptus.ru> From: Artem Viklenko Organization: Art&Co. Message-ID: Date: Wed, 4 Dec 2019 10:55:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: <20191204074703.GA88680@admin.sibptus.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (alf.viklenko.net [192.168.32.61]); Wed, 04 Dec 2019 10:55:20 +0200 (EET) X-Rspamd-Queue-Id: 47SXk329K3z4bQv X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.64 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[viklenko.net:s=alf-mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[viklenko.net:+]; DMARC_POLICY_ALLOW(-0.50)[viklenko.net,reject]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.64)[ipnet: 2001:470::/32(-4.64), asn: 6939(-3.53), country: US(-0.05)]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Wed, 04 Dec 2019 08:55:24 -0000 On 04.12.19 09:47, Victor Sudakov wrote: > Artem Viklenko via freebsd-pf wrote: > >> Had to build test lab.... > > Thank you for your time. > >> >> I still not 100% sure about state-policy - can't check it now. >> But it definitelly can influence on the final result. > > Let's stick to the default floating state-policy for now. No need to make > the lab more complicated. > >> >> Simple ruleset: > > Once you have invested your time to build the lab, could you please > reproduce my ruleset exactly (I'll repeat it below)? Unlike yours, my > ruleset has *all* rules bound to interfaces. It would be also very nice of > you to use the same IP addresses so that we did not have to translate the > addresses mentally. Actually, no. Seems I've provided enougth examples. > > [dd] > >> >> Traffic coming in the system was inspected by pf >> rules and first state was created. Then traffic going out to destination >> via another interface was inspected by pf again and second state was >> created by the same rule #1. >> >> ICMP replies going in reverse direction pass due to these states. > > Why would you need two states to pass the replies, that is the > question. If the rule is floating, why is one rule not enough? > Not I need - this is how PF works. > [dd] > >> >> This is because by default pf allows traffic but not create states. >> You can start pf with empty ruleset and see no states while traffic >> passing firewall. > > No doubt about it. But I was not talking about the complete absense of > states. Please see below. > >> >> So then traffic came back it was blocked by last matched rule with >> keyword in which is rule #2 in this case. > > No, in my case *one* state is being created. The question is why this one > available state is not enough to pass return traffic? Please peruse the pfctl > output I provide below: > > A brief repetition of what I was doing. I'd be grateful if you replicate it. Similar case - from the traffic point of view - already in my post with explanations. > > 1. Interface configuration > > hostname="fw.test" > ifconfig_vtnet0="DHCP description Outside" > ifconfig_vtnet1="172.16.1.1/24 description DMZ" > ifconfig_vtnet2="192.168.10.1/24 description Inside" > > 2. Ping configuration > > Pinging 172.16.1.10 (dmz host) from 192.168.10.3 (inside host). > > 3. Rules > > root@fw:~ # pfctl -vvs rules > No ALTQ support in kernel > ALTQ related functions disabled > @0 pass in on vtnet1 all flags S/SA keep state > [ Evaluations: 9596 Packets: 1 Bytes: 84 States: 0 ] > [ Inserted: uid 0 pid 1343 State Creations: 1 ] > @1 block drop in on vtnet1 inet from any to 192.168.0.0/16 > [ Evaluations: 2955 Packets: 2954 Bytes: 248136 States: 0 ] > [ Inserted: uid 0 pid 1343 State Creations: 0 ] > @2 pass in on vtnet2 all flags S/SA keep state > [ Evaluations: 6641 Packets: 2955 Bytes: 248220 States: 1 ] > [ Inserted: uid 0 pid 1343 State Creations: 2 ] > root@fw:~ # > > > 4. State while pinging: > > root@fw:~ # pfctl -vvs states > No ALTQ support in kernel > ALTQ related functions disabled > all icmp 172.16.1.10:33794 <- 192.168.10.3:33794 0:0 > age 00:51:57, expires in 00:00:10, 2970:0 pkts, 249480:0 bytes, rule 2 > id: 000000005de756c8 creatorid: 9da41898 > root@fw:~ # > > > 5. Question: > > We see that a floating state "172.16.1.10:33794 <- 192.168.10.3:33794" has been > created by rule 2. Why is this state not passing ICMP replies from 172.16.1.10 to > 192.168.10.3 ? I.e. why is this state not overriding the blocking rule 1 ? > > -- Regards! From owner-freebsd-pf@freebsd.org Wed Dec 4 10:29:01 2019 Return-Path: Delivered-To: freebsd-pf@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 3B0AF1A812A for ; Wed, 4 Dec 2019 10:29:01 +0000 (UTC) (envelope-from maximos@als.nnov.ru) Received: from mx.als.nnov.ru (mx.als.nnov.ru [95.79.102.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47SZp325mpz3C6T for ; Wed, 4 Dec 2019 10:28:58 +0000 (UTC) (envelope-from maximos@als.nnov.ru) Received: from [10.4.1.100] by mx.als.nnov.ru with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1icRtp-000CH3-J8 for freebsd-pf@freebsd.org; Wed, 04 Dec 2019 13:28:49 +0300 Subject: Re: pf's states To: freebsd-pf@freebsd.org References: <20191202025642.GA99174@admin.sibptus.ru> <90c1b342-b88a-a9bc-d475-4e6cd027f25c@als.nnov.ru> <20191202134047.GA14183@admin.sibptus.ru> From: Max Message-ID: <0c189ef5-61a3-209b-84a1-9982fde94073@als.nnov.ru> Date: Wed, 4 Dec 2019 13:28:49 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191202134047.GA14183@admin.sibptus.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru X-Rspamd-Queue-Id: 47SZp325mpz3C6T X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of maximos@als.nnov.ru designates 95.79.102.161 as permitted sender) smtp.mailfrom=maximos@als.nnov.ru X-Spamd-Result: default: False [-2.29 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.992,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[nnov.ru]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; IP_SCORE(0.00)[country: RU(0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42682, ipnet:95.79.0.0/16, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Wed, 04 Dec 2019 10:29:01 -0000 You should explicitly pass initial packet(s) through both interfaces. We have following rules: @0 pass in on $dmz @1 block in on $dmz from any to 192.168.0.0/16 @2 pass in on $inside 1. first packet arriving on $inside from 192.168.10.3 to 172.16.1.10 2. pf searching a state using a hash based on src and dst 192.168.10.3-172.16.1.10 3. there is no such state 4. maching against ruleset 5. using rule @2 6. creating a state with key 192.168.10.3-172.16.1.10 7. making routing decision 8. sending a packet through $dmz from 192.168.10.3 to 172.16.1.10 9. pf recieving outgoing packet, in this case reversing src and dst 10. searching a state using a key 172.16.1.10-192.168.10.3 11. there is no such state 12. using default pass, no state created 13. recieving reply on $dmz from 172.16.1.10 to 192.168.10.3 14. searching a state using a (straight) key 172.16.1.10-192.168.10.3 15. there is no such state 16. matching against ruleset 17. using rule @1 Hope I am correct. :) So, you can modify first rule: @0 pass on $dmz (no direction keyword) Now pf can create a state when sending initial packet from 192.168.10.3 to 172.16.1.10. Outgoing packet will generate a state with reversed key 172.16.1.10-192.168.10.3. Then reply packet(s) will match this state (traffic from 172.16.1.10 to 192.168.10.3). Or you can create "pass out on $dmz..." rule. 02.12.2019 16:40, Victor Sudakov пишет: > Max wrote: >> Is this a complete ruleset? > For this lab, yes, almost complete. There is only one more line, > "nat on $outside ...", but strickly speaking, "nat" is not a rule. > >> What about "pass out..." rules? > Why would I need them? In pf, it's "pass" by default. > >> You should >> check other rules since you have no "quick" in your listed rules. > 1. There are no other rules. > > 2. Even if there were, they should be irrelevant because the > "pass in on $inside" rule should create state, and states are processed > before rules. > >> The last matching rule decides what action is taken. > The last matching rule on the $inside interface is > "pass in on $inside". > > The last matching rule on the $outside interface is > "block in on $dmz from any to 192.168.0.0/16" > > From owner-freebsd-pf@freebsd.org Wed Dec 4 14:00:03 2019 Return-Path: Delivered-To: freebsd-pf@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 7492A1BE116 for ; Wed, 4 Dec 2019 14:00:03 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47SgTZ34Fqz3Mqn for ; Wed, 4 Dec 2019 14:00:02 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=TVFVA64lD3yLtcD2khemWVAea4pK4upaslOcDSZdXP4=; b=eXDNfJe2CyIZHVT1bpEt2+AEtx IYxbeHBUx6Elyf36HW5fCrpRtUuhaoKTitS9kyfqUl8enUuVVElhAzTCuCrg4IHhcuoqPsD9Zb06Z 8afjzr+dXyBw6bF7uOdYGCJ2aOKGKDn93i6odNB/1mVU6EvODvEIziTGE4zFU5T6pqyg=; Received: from vas by admin.sibptus.ru with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1icVCC-000PSp-NC for freebsd-pf@freebsd.org; Wed, 04 Dec 2019 21:00:00 +0700 Date: Wed, 4 Dec 2019 21:00:00 +0700 From: Victor Sudakov To: freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <20191204140000.GA96563@admin.sibptus.ru> References: <20191202025642.GA99174@admin.sibptus.ru> <90c1b342-b88a-a9bc-d475-4e6cd027f25c@als.nnov.ru> <20191202134047.GA14183@admin.sibptus.ru> <0c189ef5-61a3-209b-84a1-9982fde94073@als.nnov.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <0c189ef5-61a3-209b-84a1-9982fde94073@als.nnov.ru> X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47SgTZ34Fqz3Mqn X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=eXDNfJe2; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-8.48 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.38)[ip: (-9.87), ipnet: 2001:19f0:5000::/38(-4.94), asn: 20473(-2.04), country: US(-0.05)]; DKIM_TRACE(0.00)[sibptus.ru:+]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Wed, 04 Dec 2019 14:00:03 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Max wrote: > You should explicitly pass initial packet(s) through both interfaces. Max, is this requirement documented somewhere? This is becoming very interesting and educational.=20 Thank you for the great analysis, but may I ask you some more questions? >=20 > We have following rules: > @0 pass in on $dmz > @1 block in on $dmz from any to 192.168.0.0/16 > @2 pass in on $inside >=20 > 1. first packet arriving on $inside from 192.168.10.3 to 172.16.1.10 > 2. pf searching a state using a hash based on src and dst=20 > 192.168.10.3-172.16.1.10 > 3. there is no such state > 4. maching against ruleset > 5. using rule @2 > 6. creating a state with key 192.168.10.3-172.16.1.10 And this state does not allow traffic in the reverse direction (172.16.1.10 -> 192.168.10.3)?=20 That is probably the cause of my confusion. As a person with some ipfw background, I'm used to the fact that ipfw's dynamic rules are bidirectional. It is documented, and "ipfw -d list" shows them as such, e.g. 65500 STATE udp 192.168.3.76 61152 <-> 192.168.1.1 53 :default But why would pf need such unidirectional states at all? Is their purpose different from ipfw's keep-state/dynamic rules? > 7. making routing decision > 8. sending a packet through $dmz from 192.168.10.3 to 172.16.1.10 > 9. pf recieving outgoing packet, in this case reversing src and dst > 10. searching a state using a key 172.16.1.10-192.168.10.3 > 11. there is no such state > 12. using default pass, no state created > 13. recieving reply on $dmz from 172.16.1.10 to 192.168.10.3 > 14. searching a state using a (straight) key 172.16.1.10-192.168.10.3 > 15. there is no such state > 16. matching against ruleset > 17. using rule @1 >=20 > Hope I am correct. :) Yes, I think this explains perfectly what's happening. I somehow was thinking that the state created at Step 6 would be found and used at Step 14-15. >=20 > So, you can modify first rule: > @0 pass on $dmz (no direction keyword) > Now pf can create a state when sending initial packet from 192.168.10.3= =20 > to 172.16.1.10. Outgoing packet will generate a state with reversed key= =20 > 172.16.1.10-192.168.10.3. Then reply packet(s) will match this state=20 > (traffic from 172.16.1.10 to 192.168.10.3). I prefer rules bound to interfaces, Cisco-style. >=20 > Or you can create "pass out on $dmz..." rule. Yeah, that sounds great. The ping responses begin to arrive at 192.168.10.= 3! Victory! Let's see what happens to the rules and states (the added rule becomes @2): oot@fw:~ # pfctl -vvs rules No ALTQ support in kernel ALTQ related functions disabled @0 pass in on vtnet1 all flags S/SA keep state [ Evaluations: 3074 Packets: 0 Bytes: 0 States: 0 = ] [ Inserted: uid 0 pid 1482 State Creations: 0 ] @1 block drop in on vtnet1 inet from any to 192.168.0.0/16 [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 = ] [ Inserted: uid 0 pid 1482 State Creations: 0 ] @2 pass out on vtnet1 all flags S/SA keep state [ Evaluations: 1 Packets: 4630 Bytes: 388920 States: 1 = ] [ Inserted: uid 0 pid 1482 State Creations: 1 ] @3 pass in on vtnet2 all flags S/SA keep state [ Evaluations: 3074 Packets: 4630 Bytes: 388920 States: 1 = ] [ Inserted: uid 0 pid 1482 State Creations: 1 ] root@fw:~ # root@fw:~ # pfctl -vvs states No ALTQ support in kernel ALTQ related functions disabled all icmp 172.16.1.10:33794 <- 192.168.10.3:33794 0:0 age 00:43:38, expires in 00:00:10, 2498:2498 pkts, 209832:209832 bytes, = rule 3 id: 000000005de764a4 creatorid: 4e14336a all icmp 192.168.10.3:33794 -> 172.16.1.10:33794 0:0 age 00:43:38, expires in 00:00:10, 2498:2498 pkts, 209832:209832 bytes, = rule 2 id: 000000005de764a5 creatorid: 4e14336a root@fw:~ # I begin to see two identical (?) floating states. I call them identical bec= ause both denote the direction of traffic "192.168.10.3 -> 172.16.1.10". There i= s not a state with (reversed) key "172.16.1.10 -> 192.168.10.3", but the return traffic is now somehow magically passed. I'm mystified again. --=20 Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJd57vgAAoJEA2k8lmbXsY0LWQIAIIDubBX9ISydwGH4Q17dOCF qyqk8FAUMU1/FusENdmWERWb6KpCntf6BapNC4cbXFJCU9Mtp4DjIq8EzbNGKGSp DeFzrVcAA/CwqHmOhg47Gr54hE+ZEJ9m2uMCvs20Dp1wrlqXJzgYcjgp/7XKy2vC ZFjbO49U3FeRQJ785GkaSx+0QkMYbjFfgEhrGnUQT+OTWVLwEmCFRsHwK5CI62DX ue7gLqsYXkBIjWiRUMde0+qP0poeh11JQ2kLdXXm5+xgUrjl0KljQrJyLYRqxOzb 8V0kaFHUEMJaW4jKgnx+dFwF3Rts7ayrCntO3r51X8c+7BPzUljCxgINq+H8HIg= =tb6i -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From owner-freebsd-pf@freebsd.org Thu Dec 5 04:24:39 2019 Return-Path: Delivered-To: freebsd-pf@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 50B9F1BA113 for ; Thu, 5 Dec 2019 04:24:39 +0000 (UTC) (envelope-from vas@sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47T2gB16L2z3G0Q for ; Thu, 5 Dec 2019 04:24:37 +0000 (UTC) (envelope-from vas@sibptus.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=Aac700V+R81PY/2d/trDCA7ilZliCSq8Hs1e6/4+Qiw=; b=Q3OfW7rCU8Y4XJKGDB99dkNFTc EJ5Mmz40l2T6yCcBIMtxzpJpPkh9RhK0+fNxbkUng25EGUgTWlvMhPTltuseHhGGpV7xs46WBBNog 43ReyHAXnoRm5zhdGTnldjOfXoSSbUaMz/90HzW5zv03aCA4ULRhuI/eQfvjlLHQPvnI=; Received: from vas by admin.sibptus.ru with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1icigt-0005P2-PS for freebsd-pf@freebsd.org; Thu, 05 Dec 2019 11:24:35 +0700 Date: Thu, 5 Dec 2019 11:24:35 +0700 From: Victor Sudakov To: freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <20191205042435.GA19962@admin.sibptus.ru> References: <20191202025642.GA99174@admin.sibptus.ru> <90c1b342-b88a-a9bc-d475-4e6cd027f25c@als.nnov.ru> <20191202134047.GA14183@admin.sibptus.ru> <0c189ef5-61a3-209b-84a1-9982fde94073@als.nnov.ru> <20191204140000.GA96563@admin.sibptus.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <20191204140000.GA96563@admin.sibptus.ru> X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47T2gB16L2z3G0Q X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=Q3OfW7rC; dmarc=pass (policy=none) header.from=sibptus.ru; spf=pass (mx1.freebsd.org: domain of vas@sibptus.ru designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@sibptus.ru X-Spamd-Result: default: False [-8.48 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.38)[ip: (-9.87), ipnet: 2001:19f0:5000::/38(-4.94), asn: 20473(-2.05), country: US(-0.05)]; DKIM_TRACE(0.00)[sibptus.ru:+]; DMARC_POLICY_ALLOW(-0.50)[sibptus.ru,none]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Thu, 05 Dec 2019 04:24:39 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Victor Sudakov wrote: > Max wrote: [dd] > >=20 > > Or you can create "pass out on $dmz..." rule. >=20 > Yeah, that sounds great. The ping responses begin to arrive at 192.168.1= 0.3! > Victory! You know what! If I create a "pass out on $dmz..." rule, no rules on $inside are necessary any more. pfctl shows only *one* state, but this time it is sufficient: root@fw:~ # pfctl -vvs rules No ALTQ support in kernel ALTQ related functions disabled @0 pass in on vtnet1 all flags S/SA keep state [ Evaluations: 15 Packets: 0 Bytes: 0 States: 0 = ] [ Inserted: uid 0 pid 1262 State Creations: 0 ] @1 block return in on vtnet1 inet from any to 192.168.0.0/16 [ Evaluations: 1 Packets: 1 Bytes: 84 States: 0 = ] [ Inserted: uid 0 pid 1262 State Creations: 0 ] @2 pass out on vtnet1 all flags S/SA keep state [ Evaluations: 1 Packets: 0 Bytes: 0 States: 0 = ] [ Inserted: uid 0 pid 1262 State Creations: 0 ] root@fw:~ # root@fw:~ # pfctl -vvs states No ALTQ support in kernel ALTQ related functions disabled all icmp 192.168.10.3:63234 -> 172.16.1.10:63234 0:0 age 00:00:11, expires in 00:00:09, 11:11 pkts, 924:924 bytes, rule 2 id: 000000005de88142 creatorid: 68441fab root@fw:~ # Now 192.168.10.3 can ping 172.16.1.10 and receive echo replies, 172.16.1.10 cannot ping 192.168.10.3. Don't you think there is something non-trivial or even incorrect about the way states are evaluated? --=20 Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJd6IaDAAoJEA2k8lmbXsY0IYUIAIck74EMMDpv+vqoDpwxIE+I exMcI6MJ/D6p12cTQp5Vdbjnrsp74XQrDRxPyymzP+p36g6BpU/iLqmDGM8aFPWf gCDgBHLHlFxTJFhZ9WOXe5jGZdtL9iQu6lOcA6gI0tX5U0UaeHgmtuEla2P1Ro5N IA6AT5qKbCIjevd2dS7lvztDv61KvAuSrEtPsk/CoklmQHvQcsTYvK0yywXnVLER D3Q38daLFUV8JWQXbVJLVrhbNkkLe3Zm0/PuNtk+AzMIb8mqF3tRjZnYUPBV7abm W7hOtLhu1cb5J5exrojY/BSCZq1dCMw1TymBTfX2wQmz8lCklVsNXf1HDYwz1jM= =6yG1 -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- From owner-freebsd-pf@freebsd.org Thu Dec 5 05:33:34 2019 Return-Path: Delivered-To: freebsd-pf@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 9ACEA1BBC7F for ; Thu, 5 Dec 2019 05:33:34 +0000 (UTC) (envelope-from maximos@als.nnov.ru) Received: from mx.als.nnov.ru (mx.als.nnov.ru [95.79.102.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47T4Bh0kD8z3Jsh for ; Thu, 5 Dec 2019 05:33:31 +0000 (UTC) (envelope-from maximos@als.nnov.ru) Received: from [10.4.1.100] by mx.als.nnov.ru with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1icjlY-0009HD-F6 for freebsd-pf@freebsd.org; Thu, 05 Dec 2019 08:33:28 +0300 Subject: Re: pf's states To: freebsd-pf@freebsd.org References: <20191202025642.GA99174@admin.sibptus.ru> <90c1b342-b88a-a9bc-d475-4e6cd027f25c@als.nnov.ru> <20191202134047.GA14183@admin.sibptus.ru> <0c189ef5-61a3-209b-84a1-9982fde94073@als.nnov.ru> <20191204140000.GA96563@admin.sibptus.ru> <20191205042435.GA19962@admin.sibptus.ru> From: Max Message-ID: Date: Thu, 5 Dec 2019 08:33:28 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191205042435.GA19962@admin.sibptus.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru X-Rspamd-Queue-Id: 47T4Bh0kD8z3Jsh X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of maximos@als.nnov.ru designates 95.79.102.161 as permitted sender) smtp.mailfrom=maximos@als.nnov.ru X-Spamd-Result: default: False [-2.28 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[nnov.ru]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; IP_SCORE(0.00)[country: RU(0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42682, ipnet:95.79.0.0/16, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Thu, 05 Dec 2019 05:33:34 -0000 No. You have no block rules on $inside (no rules at all in this case). PF uses default pass with no states. I think we should consider the traffic flow from the firewall's point of view. It has incoming and outgoing flows. That's all. Transitional flow is just a combination of incoming and outgoing. If we have incoming packets from some source ip (straight flow) then reversed packets will flow to that source ip. When we send packets to some destination ip (staright flow) the reversed will be arriving from that destination ip. No matter if we use one interface or two. So, in the case of transitional connection it will be: 1. recieving packet from src to dst (incoming) 2. creating state src-dst allowing to pass replies TO src (and straignt flow from src) 3. routing 4. sending packet from src to dst (outgoing) 5. creating state dst-src allowing to pass replies FROM dst (and straight flow to dst) > root@fw:~ # pfctl -vvs states > No ALTQ support in kernel > ALTQ related functions disabled > all icmp 172.16.1.10:33794 <- 192.168.10.3:33794 0:0 > age 00:43:38, expires in 00:00:10, 2498:2498 pkts, 209832:209832 bytes, rule 3 > id: 000000005de764a4 creatorid: 4e14336a > all icmp 192.168.10.3:33794 -> 172.16.1.10:33794 0:0 > age 00:43:38, expires in 00:00:10, 2498:2498 pkts, 209832:209832 bytes, rule 2 > id: 000000005de764a5 creatorid: 4e14336a > root@fw:~ # > > I begin to see two identical (?) floating states. I call them identical because > both denote the direction of traffic "192.168.10.3 -> 172.16.1.10". There is not > a state with (reversed) key "172.16.1.10 -> 192.168.10.3", but the return > traffic is now somehow magically passed. I'm mystified again. They are distinguish. "<-" means incoming flow, "->" means outgoing flow. 05.12.2019 7:24, Victor Sudakov пишет: > Victor Sudakov wrote: >> Max wrote: > [dd] > >>> Or you can create "pass out on $dmz..." rule. >> Yeah, that sounds great. The ping responses begin to arrive at 192.168.10.3! >> Victory! > You know what! If I create a "pass out on $dmz..." rule, no rules on > $inside are necessary any more. pfctl shows only *one* state, but this time > it is sufficient: > > root@fw:~ # pfctl -vvs rules > No ALTQ support in kernel > ALTQ related functions disabled > @0 pass in on vtnet1 all flags S/SA keep state > [ Evaluations: 15 Packets: 0 Bytes: 0 States: 0 ] > [ Inserted: uid 0 pid 1262 State Creations: 0 ] > @1 block return in on vtnet1 inet from any to 192.168.0.0/16 > [ Evaluations: 1 Packets: 1 Bytes: 84 States: 0 ] > [ Inserted: uid 0 pid 1262 State Creations: 0 ] > @2 pass out on vtnet1 all flags S/SA keep state > [ Evaluations: 1 Packets: 0 Bytes: 0 States: 0 ] > [ Inserted: uid 0 pid 1262 State Creations: 0 ] > root@fw:~ # > > root@fw:~ # pfctl -vvs states > No ALTQ support in kernel > ALTQ related functions disabled > all icmp 192.168.10.3:63234 -> 172.16.1.10:63234 0:0 > age 00:00:11, expires in 00:00:09, 11:11 pkts, 924:924 bytes, rule 2 > id: 000000005de88142 creatorid: 68441fab > root@fw:~ # > > Now 192.168.10.3 can ping 172.16.1.10 and receive echo replies, 172.16.1.10 > cannot ping 192.168.10.3. > > Don't you think there is something non-trivial or even incorrect about the > way states are evaluated? >