===================================
# 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
_______________________________________________
freebsd-pf@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
