From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 04:45:09 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3901F106566C for ; Mon, 3 Mar 2008 04:45:09 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by mx1.freebsd.org (Postfix) with ESMTP id D4E228FC1F for ; Mon, 3 Mar 2008 04:45:08 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id B23BB5A7463; Mon, 3 Mar 2008 02:45:13 -0200 (ARDT) Received: from notebook.gont.com.ar (201-254-62-65.speedy.com.ar [201.254.62.65] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m234iqVp004383; Mon, 3 Mar 2008 02:44:52 -0200 Message-Id: <200803030444.m234iqVp004383@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 03 Mar 2008 02:42:58 -0200 To: "Bruce M. Simpson" From: Fernando Gont In-Reply-To: <47CB3CED.7070303@FreeBSD.org> References: <200803011338.m21DcY9Z026418@venus.xmundo.net> <47CB3CED.7070303@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 03 Mar 2008 02:45:13 -0200 (ARDT) Cc: Rui Paulo , freebsd-net@FreeBSD.org Subject: Re: Ephemeral port range (patch) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 04:45:09 -0000 At 09:49 p.m. 02/03/2008, you wrote: >+1 on increasing the threshold, 1024 is way too low. With the current patch, I agree. I'm planning to implement the scheme described in the port randomization internt-draft I referenced, and implement the array-of-bits thing. That way you can exclude whichever ports you want, without "wasting" the 1024-9999 port range. >Also consider the folk who depend on the existing behaviour: a >predictable ephemeral port range is useful, if for some reason you >need to apply a NAT policy to that traffic, with no other >knowledge about how the applications you must NAT actually behave. You can still set porthi or portlow to select whichever port range you want. The patch just changes the default case. As noted in one of the sections of the draft I referenced, turns put that each TCP/IP stack chooses its own range for the ephemeral ports. So unless you're tweaking the configuration of each of the systems you have behind the NAT, I'm afraid you won't be able to implement such a policy. FWIW, Windows used the range 1024-4999 or something... at least W95 and XP. Vista probably still does the same thing. Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1