pf's states

[Morgan Wesström]

>>> ===================================
>>> # 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.
>>
>> Rule 1 does not match this packet
>> Rule 3 matches said packet, action is PASS

The pass directive creates a state when only SYN is set out of SYN and 
ACK as per the manual page. It does NOT create a state when both SYN and 
ACK is set simultaneously as in your initial reply from the telnet 
server. Afaik a pass rule only creates state on the interface it 
monitors. I did not recreate your setup to check this though. But this 
is what should happen:

With rule 2 remarked:

- Your initial telnet SYN will create state on $inside through rule 3.
- There should be no state created on $dmz.
- Your SYN+ACK reply and further replies will be passed by pf's default 
pass behaviour on $dmz.

With rule 2 active:

- Your initial telnet SYN will create state on $inside through rule 3.
- There should be no state created on $dmz.
- Your SYN+ACK reply and further replies will be blocked by rule 2 since 
they match this rule and there are no states on $dmz to take precedence.

My advice is to create ingoing and outgoing pass rules on both 
interfaces and to specify the state/flags combination even if they're 
the default. This way you will create states on both interfaces as you 
expect and additionally not run into nasty surprises if the default 
behaviour is changed in a future version of pf.

pass in  on $dmz flags S/SA keep state
pass out on $dmz flags S/SA keep state
pass in  on $inside flags S/SA keep state
pass out on $inside flags S/SA keep state

/Morgan