Kajetan Staszkiewicz wrote: > > > > I was asking this question on the freebsd-net mailing list, but I think > > it would be better to re-ask it here. > > > > There is something I cannot understand about pf's notion of state. > > > > Consider this very simple example with two interfaces: > > > > =================================== > > # DMZ 172.16.1.0/24 > > pass in on $dmz > > #block in on $dmz from any to 192.168.0.0/16 > > > > # Inside 192.168.10.0/24 > > pass in on $inside > > =================================== > > > > While the "block ..." line is commented out, I can "telnet 172.16.1.10 80" > > from 192.168.10.3. > > 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. > > 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.10. > > 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" > > > But when I uncomment the "block ..." line and restart pf, I cannot do > > that any more. Why is that? > > 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? > > 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. > > 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 after running "vi /etc/pf.conf ; service pf restart" on the firewall. [dd] > > > 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 > > 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 bridge0 interface on the firewall). > > > so I must be wrong in my understaning how > > state works. > > 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. > > The last thing I would like to point out is that your firewall lacks > final blocking rule. 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. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
signature.asc
Description: PGP signature
