kern/121668: connect randomly fails with EPERM with some pf
rules
Laurent Frigault
lfrigault at agneau.org
Thu Mar 13 22:50:06 UTC 2008
The following reply was made to PR kern/121668; it has been noted by GNATS.
From: Laurent Frigault <lfrigault at agneau.org>
To: Kian Mohageri <kian at restek.wwu.edu>
Cc: bug-followup at FreeBSD.org
Subject: Re: kern/121668: connect randomly fails with EPERM with some pf rules
Date: Thu, 13 Mar 2008 23:49:43 +0100
On Thu, Mar 13, 2008 at 12:44:48PM -0700, Kian Mohageri wrote:
> >> I remember similar behavior and it was caused by source port reuse
> >> on the client (so the new connection caused a state mismatch on an
> >> old state).
> >
> > The previous connection are closed.
> > If the source port can't be reused yet, then the kernel should use an
> > other one for the new connection. If it can, then pf should allow it.
> >
> > If the connect (SYN) does not match an existing state, The pf rule
> > should create a new state.
>
> It does "match" a state (source/dest is same), which is the problem.
ok.
> Even though the connection is closed, the state hasn't yet been purged.
> Refer to pf.conf(5) for how to adjust tcp.closed so the state is purged
> sooner, or adjust the available dynamic port range (sysctl
> net.inet.ip.portrange).
I try to disable net.inet.ip.portrange.randomized and set tcp.closed
timeout to 0.
That seems to work arround the problem in most cases.
Are there any risk at setting the timeout to 0 ?
> I don't know if this is intended behavior or not. I've never run into
> it on OpenBSD, but pf is integrated much more tightly into their
> system obviously and I'm guessing their port reuse code is pretty
> different too.
Maybe the port randomization is different too.
--
Laurent Frigault | <url:http://www.agneau.org/>
More information about the freebsd-pf
mailing list