From owner-freebsd-net@FreeBSD.ORG Wed Apr 18 19:12:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22AE61065743 for ; Wed, 18 Apr 2012 19:12:44 +0000 (UTC) (envelope-from dmk.sbor@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id CD3BB8FC17 for ; Wed, 18 Apr 2012 19:12:43 +0000 (UTC) Received: by yenl9 with SMTP id l9so4727505yen.13 for ; Wed, 18 Apr 2012 12:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7SYZLAafb/+XMEmOV69wYB5xziQNkox/w6SxQNpmTu0=; b=ivMmyesQW4+I4/mwjd4Hx9hcUvveQT30kclhdhxw1IK6+zmy9nMxy+fh2wjP09XLi4 kMAohRIohIwpcKVtJ6YYvX8OGu+FqC3HRVQlwTtL9Yuiv+21ZHLdVcOLyvLWu1ypESV1 EPOYPV8VHzV1K8mBhJ44xlaQ75vk6A4+mRDbNMbt31x6ZUXCbkWIwiz30gCd/id3caIL xexJO9HtWd/PwZCh0F6o9JVuZXHUoXqsNQFyrurAvji9h+ZDD59uBWrji9J1y4WDmnpz a6RMBoEVN/XeOF0lP6PNfsnzlRX1oKbMdA264kfFVJL3lFQkxKCNe5sK3qRJniknhSpk Qm8w== MIME-Version: 1.0 Received: by 10.236.193.39 with SMTP id j27mr3483535yhn.111.1334776363111; Wed, 18 Apr 2012 12:12:43 -0700 (PDT) Received: by 10.146.168.1 with HTTP; Wed, 18 Apr 2012 12:12:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Apr 2012 23:12:42 +0400 Message-ID: From: "Dmitry S. Kasterin" To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org, Michael Sierchio Subject: Re: Stateful IPFW - too many connections in FIN_WAIT_2 or LAST_ACK states 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: Wed, 18 Apr 2012 19:12:44 -0000 Kevin, Michael, hi > a real problem with IPFW. Well, someone who can confirm or disprove my guesswork is much desirable ) > But I do have to ask why you find statefull rules for outgoing TCP > connections desirable? Why not: > 00101 allow tcp from me to any established > It appears to do the same thing for TCP and is much faster to process > plus it does not leave you open to trivial DOS (often of yourself) by > filling the dynamic rule tables. The host in question is my workstation running FreeBSD. I have no reason to distrust its users. Workstation doesn't host services. So I've decided to keep ruleset short and clean: 00001 allow ip from any to any via lo0 00002 deny ip from any to 127.0.0.0/8 00003 deny ip from 127.0.0.0/8 to any 00004 deny ip6 from any to any 00010 check-state 00101 allow tcp from me to any out setup keep-state 00201 allow udp from me to any out keep-state 00301 allow icmp from me to any out keep-state 00302 allow icmp from any to me in icmptypes 3,4,8,11,12 65534 deny ip from any to any 65535 deny ip from any to any Yes, I'm aware of possible DOS. But I have direct access to the workstation; if something goes wrong, I always can examine it. Thank you for the "allow tcp from me to any established" rule, I'll give it a try later. > Generally, for client systems, stateful UDP makes sense, but I > generally don't understand why people choose the more complex, slower, > and potentially disruptive stateful rules for TCP. Hmm, http://undeadly.org/cgi?action=article&sid=20060927091645 says: "For specific connections like DNS lookups, where each connection only consists of two packets (one request and one reply), the overhead of state creation might be worse than two ruleset evaluations. Connections that consist of more than a handful of packets, like most TCP connections, will benefit from the created state entry." But it doesn't matter - both stateless and stateful rules for UPD will work in my case. > Look at the kernel tunables: > ... # sysctl net.inet.ip.fw | grep _lifetime net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 I didn't change anything. Quite possible dyn_fin_lifetime is too small. I'll try to raise it.