Date: Mon, 2 Dec 2019 22:25:43 +0700 From: Victor Sudakov <vas@sibptus.ru> To: freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <20191202152543.GA16128@admin.sibptus.ru> In-Reply-To: <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> References: <20191202025642.GA99174@admin.sibptus.ru> <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191202152543.GA16128>