I think it is also worth mentioning that the connections failed (at least for me) immediately. There does not appear to be any timeouts. Initially, this is what lead me to believe it was NOT pf because my block policy was drop, not reject. When a packet is a state mismatch, doesn't it simply get discarded (assuming block policy is "drop")? If so, shouldn't the client simply assume packet was lost and retransmit, or time out after a period of time? I am having trouble understanding why the connection would fail immediately if pf was dropping packets.
That, however, should mean that disabling pf wouldn't help -- but it does. Does pf handle state-mismatch differently? Maybe a pf expert could speak on that. Kian On 6/8/06, Kian Mohageri <[EMAIL PROTECTED]> wrote:
I'm aware. I meant that as "pass quick" (without any keep state) ;) Kian On 6/8/06, Daniel Eriksson < [EMAIL PROTECTED]> wrote: > > Kian Mohageri wrote: > > > 'pass quick' (non-stateful) fixed the problems but I wasn't > > satisfied with that for obvious reasons. > > The 'quick' keyword does not make the rule non-stateful, it only aborts > further evaluation of the specific packet. > > See http://www.openbsd.org/faq/pf/filter.html#quick for more > information. > > /Daniel Eriksson >
_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
