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