From owner-freebsd-pf@FreeBSD.ORG Thu Mar 13 19:30:02 2008 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1ABF1065674 for ; Thu, 13 Mar 2008 19:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BB8EB8FC27 for ; Thu, 13 Mar 2008 19:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2DJU20p004713 for ; Thu, 13 Mar 2008 19:30:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2DJU2Px004712; Thu, 13 Mar 2008 19:30:02 GMT (envelope-from gnats) Date: Thu, 13 Mar 2008 19:30:02 GMT Message-Id: <200803131930.m2DJU2Px004712@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: Max Laier Cc: Subject: Re: kern/121668: connect randomly fails with EPERM with some pf rules X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Max Laier List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 19:30:02 -0000 The following reply was made to PR kern/121668; it has been noted by GNATS. From: Max Laier To: bug-followup@freebsd.org, lfrigault@agneau.org Cc: Subject: Re: kern/121668: connect randomly fails with EPERM with some pf rules Date: Thu, 13 Mar 2008 20:26:39 +0100 > sysctl net.inet.tcp.nolocaltimewait=1 > not needed, but helps to reproduce the problem with client and server > on the same computer. Okay, now this is just asking for trouble. pf does thorough checks on TCP states, one of which is to enforce the 2MSL quite time before port reuse. If you set above sysctl you specificly ask FreeBSD to break that rule and thus cause pf to bark. You can also hit the issue if you have a large number of (consecutive) connections between two hosts (e.g. [poorly configured] squid -> www-backends, mysql, ...). The sollution is to: 1) Reduce the connection spree and use one permanent connection 2) Increase the ephemeral port range net.inet.ip.portrange.hi{first,last} 3) Decrease the pf state timeout tcp.{closing,closed} in order to relax the check. You can do this globaly and on a per-rule basis. -- Max