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--