[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some problems with pf losing state information in
On 09/12/2002, Dries Schellekens <[email protected]> wrote To [email protected]:
> One thing people will notice in the pf.conf files is some rules that
> explicitly allow reply traffic through the firewall when a "keep state"
> parameter on the incoming traffic rule should have taken care of this
> Here's an example:
> pass in on $int_if proto tcp from $mail_relay_ok_net to $int_if port smtp
> keep state label "int_if_in_$srcaddr->$dstaddr_$dstport"
> pass in on $int_if proto udp from $name_server_ip port domain to $int_if
> keep state label "int_if_in_$srcaddr_$srcport->$dstaddr" # shouldn't need
> this line
Ehm? pf lets through e.g. returning icmp-unreachables, but a complete
"off" dns reply is not part of the state.
> When I watched the log of blocked packets, I'd find that a small number of
> reply packets were getting blocked until I added reply rules like the
> second one above. It appeared that pf was losing track of the state of
> certain incoming connections and so generated reply traffic wasn't being
> correctly associated with incoming traffic.
I guess you are used to iptables, where a 'related'-rule also takes care
of such things (and this IS evil).
> Anyone experienced this? It wasn't a big problem, but I shouldn't have
> needed those extra rules. This is with release OpenBSD 3.2.
It's ok this way. You dont want "silly" application-layer "analysis" about
what's a corresponding dns request or whatsoever (inetd comes to mind