Date: Sun, 8 Dec 2019 21:14:58 +0700 From: Victor Sudakov <vas@sibptus.ru> To: freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <20191208141458.GA55419@admin.sibptus.ru> In-Reply-To: <e9b9f55c-5da3-1b31-a4ab-f6233d81e219@als.nnov.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> <20191205042435.GA19962@admin.sibptus.ru> <e9b9f55c-5da3-1b31-a4ab-f6233d81e219@als.nnov.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
--zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Max wrote: > No.=20 No what? :-) > You have no block rules on $inside (no rules at all in this case).=20 > PF uses default pass with no states. I have never had any block rules on $inside. May I remind the initial very simple example configuration where state was being created but did not work as I expected? # DMZ 172.16.1.0/24 pass in on $dmz=20 block in on $dmz from any to 192.168.0.0/16 # Inside 192.168.10.0/24 pass in on $inside=20 Pinging 172.16.1.10 from 192.168.10.3 creates the following state: root@fw:~ # pfctl -vvs state No ALTQ support in kernel ALTQ related functions disabled all icmp 172.16.1.10:62211 <- 192.168.10.3:62211 0:0 age 00:09:17, expires in 00:00:10, 531:0 pkts, 44604:0 bytes, rule 2 id: 000000005de8b503 creatorid: e8f0f0df root@fw:~ # This state however for some reason does not let reversed packets from $dmz to $inside, the question is why. >=20 > I think we should consider the traffic flow from the firewall's point of= =20 > view. It has incoming and outgoing flows. That's all. Transitional flow= =20 > is just a combination of incoming and outgoing. If we have incoming=20 > packets from some source ip (straight flow) then reversed packets will=20 > flow to that source ip.=20 We can talk about incoming or outgoing packets only from the point of view of an interface. But according to man pf.conf, the default state-policy is floating which means that "States can match packets on any interfaces" so there is not much use talking about directions.=20 The state as shown above does not show any affiliation with any interface. Nor can it be really called "outgoing" or "incoming" because the flow is incoming from the point of view of the $inside interface and outgoing from the point of view of the $dmz interface. > When we send packets to some destination ip=20 > (staright flow) the reversed will be arriving from that destination ip.= =20 True. > No matter if we use one interface or two. So, in the case of=20 > transitional connection it will be: > 1. recieving packet from src to dst (incoming) Yes, in this example this packet is an echo request from 192.168.10.3 to 172.16.1.10. > 2. creating state src-dst allowing to pass replies TO src (and straignt= =20 > flow from src) Yes, you can see this state "all icmp 172.16.1.10:62211 <- 192.168.10.3:622= 11" above. And it should be allowing to pass replies TO 192.168.10.3, but this is not happening. > 3. routing > 4. sending packet from src to dst (outgoing) > 5. creating state dst-src allowing to pass replies FROM dst (and=20 > straight flow to dst) Fine. Now we see an icmp reply coming from 172.16.1.10 to 192.168.10.3. Why is it *not* being checked against the state created in Step 2 and *not* passed? --=20 Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ --zhXaljGHf11kAtnf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJd7QViAAoJEA2k8lmbXsY0GRcH/iwABLMtnwoD6G09pA+tSNWw JHjhagBTqxKzcDJMcUJmkbXbK/GEZ/xVIuFKf8rzYw71XnEUNHZaU6ndou/VjplP o86qL8ecZA3wQWJVO74LeXsmQiOkLqrMw0a6wIXY97K68P4QXQRoz6gBywhQ4/pM pGqT6yWlug2TLu0Pu46O39oUwYXciptvmqZLeGvO7V/89bOi6irdIcaihb0yzigN UmmCZNoUD3mIUDnmSYWdBLoiO6E9t0EL2GN0KH2nKviFS2ahWmKSWMDmm4M88FY8 ac8GqEOmb+WqwBBheNE62K4f0GMrXyMsYHOZMKTrCB/ARKvjlI7iw9z4x2jOoHM= =xTib -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191208141458.GA55419>