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