Date: Wed, 4 Dec 2019 21:00:00 +0700 From: Victor Sudakov <vas@sibptus.ru> To: freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <20191204140000.GA96563@admin.sibptus.ru> In-Reply-To: <0c189ef5-61a3-209b-84a1-9982fde94073@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191204140000.GA96563>