From owner-freebsd-pf@FreeBSD.ORG Tue Apr 24 14:18:58 2007 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6716216A400 for ; Tue, 24 Apr 2007 14:18:58 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 2D69B13C448 for ; Tue, 24 Apr 2007 14:18:57 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (unknown [89.53.124.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id A9110128829 for ; Tue, 24 Apr 2007 15:59:10 +0200 (CEST) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 7A8293F4E8 for ; Tue, 24 Apr 2007 15:58:26 +0200 (CEST) Message-ID: <462E0D08.4080505@vwsoft.com> Date: Tue, 24 Apr 2007 15:58:32 +0200 From: Volker User-Agent: Thunderbird 2.0.0.0 (X11/20070420) MIME-Version: 1.0 To: "FreeBSD (PF)" X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Subject: debugging pf X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list 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: Tue, 24 Apr 2007 14:18:58 -0000 Hi! While trying to nail down what I suspected to might be an MTU issue, using "debug urgent" I've seen a debug message like: pf: NAT proxy port allocation (50001-65535) failed >From the interpretation of the code (pf.c, function pf_get_sport) I think this function is trying to allocate a new source port to be used for NAT. If it fails, all source ports must be exhausted (or the packet is non TCP/UDP/ICMP). But in this case, all of 15,000 ports (range 50001-65535) must be in use. Near the time of this debug message, pf has had around 200 to 400 state table entries (all pf rules create state). 1) Why does pf state it's out of ports if it really isn't or am I misinterpreting the code of function pf_get_sport? 2) How do I figure out which packet (or connection) is causing this message? With loud debugging there are plenty of other (irrelevant) messages. Is there a way to direct debugging to pflog? I want to get an idea of the timing and see if this happens at the time where I expect a specific connection to fail. This gateway I'm trying to debug is serving a lot of users and I need to find the tree in the forrest. Thanks! Volker