pf buggy on 6.1-STABLE?

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 <kian.mohagerigmail.com> wrote:
>
> I'm aware.  I meant that as "pass quick"
(without any keep state) ;)
>
> Kian
>
>
> On 6/8/06, Daniel Eriksson < daniel_k_erikssontelia.com> 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-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

Just in case anyone is wondering about the same answers, I
decided to check
it out tonight.

When a packet is a state mismatch, doesn't it simply get
discarded (assuming
> block policy is "drop")?
>

It appears that pf sends a RST when a state-mismatch happens
during the
initial handshake:

		if ((*state)->dst.state == TCPS_SYN_SENT &&
> 		    (*state)->src.state == TCPS_SYN_SENT) {
> 			/* Send RST for state mismatches during handshake */
>
>
That would explain why new connections fail immediately when
the state is
mismatched.


On 6/8/06, Kian Mohageri <kian.mohagerigmail.com> wrote:
> >
> > I'm aware.  I meant that as "pass
quick" (without any keep state) ;)
> >
> > Kian
> >
> >
> > On 6/8/06, Daniel Eriksson <
daniel_k_erikssontelia.com> 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-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"