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