pf's states

[Victor Sudakov]

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 at fidonet http://vas.tomsk.ru/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20191202/0c703b11/attachment.sig>