[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some problems with pf losing state information in
On Mon, Dec 09, 2002 at 06:17:02PM +0100, Dries Schellekens wrote:
> 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
> 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.
The first rule deals with smtp connections, the second one with dns
traffic. The relation between the two might be an MTA doing DNS
resolution for smtp connections.
You didn't assume that DNS traffic indirectly caused by a TCP protocol
would be associated with the TCP state, did you?
The other explanation would be blocked DNS traffic causing timeouts in
the smtp states.
I'm afraid I can't see how you expect UDP DNS packets to be associated
with TCP connections. Again, I need a tcpdump -nvvvSpi pflog0 of a
blocked packet that you expect to be passed, and the pfctl -vss of the
state you expect it to be associated with.