From owner-freebsd-questions@freebsd.org Wed Jan 11 12:05:12 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22EEACA7ADC for ; Wed, 11 Jan 2017 12:05:12 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2EAB1F78 for ; Wed, 11 Jan 2017 12:05:11 +0000 (UTC) (envelope-from ml@my.gd) Received: by mail-ua0-x22b.google.com with SMTP id i68so404692883uad.0 for ; Wed, 11 Jan 2017 04:05:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=my-gd.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=9x6KH+o1WLN4zCso7mg77GFIgm8v1sknHlv4+t0wXFc=; b=YIS9gX/oSkGRuOeiBznYZ4QywowNh4YL9H/eRsSP4NdsbR2v9B0kLeOFNYhxQ45Lr5 QYrfSRKuT360KbhYek/Hfp0uM/2EymCyRxg4M7ptYcexzPZscdLOjUfSxqcCampjijNK ZxLVRYPSuivaliLWZdfG9rIyGOzetA02AyC+kN52drQkhHDuuDNXSYU0LjZ1Nqgx7HnV 5CJpxidts7tJ89PzTBshbekTDGivHMxUVH4b66YLrCKRLDKivREXwR63o0ERIQwvkF8z MutmYzOd33Vz2Ru3pSIFd8MrFs/8w+mWgE/NfKmLCeqH5YRgWZbb078NxA+NsfT0mVhV GQOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=9x6KH+o1WLN4zCso7mg77GFIgm8v1sknHlv4+t0wXFc=; b=ABFk0C/bvJitZnShjxSfhRiKb9qsbI0Nq+JIF6mnQlkEkDLQ/3Kp1/JkPW9h/lDHW4 jabYTrtljnWG57ZwPM82kzUhmx5ltaF/teMvbrkXF41qHRNuhrxpf3ACvY2rjRAGeFrx ZbF7aPxOi9DK9Hxkadvr7I9rqC9pxHAFGLA1sFsPnG5kmXmh0DYIBlYlRLZuiEpfyrEh F174xfqvpB0t11u7e+l07IZxGALVo4KCzUk7CuMoDjFheFJItDe5SUZEmIHBmJvAACxh biek/61J8MzcAcbnt8s0SAe8qei7P1KOP8FSdkrh/qrlbHIwfmpACCiDCjKXQNdNJEFo pZMQ== X-Gm-Message-State: AIkVDXIFEk+VGcIxV1NwzgiKIZIelGjLKxm7VssoKcyDYVeEb7r2tWE15EO8UcHpUGBoI8xEnieGsijhGzuWag== X-Received: by 10.176.1.174 with SMTP id 43mr4429773ual.44.1484136311012; Wed, 11 Jan 2017 04:05:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.48.213 with HTTP; Wed, 11 Jan 2017 04:05:10 -0800 (PST) In-Reply-To: <20170111102445.GA53285@slackbox.erewhon.home> References: <20170111102445.GA53285@slackbox.erewhon.home> From: Damien Fleuriot Date: Wed, 11 Jan 2017 13:05:10 +0100 Message-ID: Subject: Re: [IPFW] stateful session timeout To: Damien Fleuriot , "freebsd-questions@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 12:05:12 -0000 On 11 January 2017 at 11:24, Roland Smith wrote: > On Tue, Jan 10, 2017 at 03:16:46PM +0100, Damien Fleuriot wrote: >> Hello list, > >> We currently use PF on 8-STABLE and 10-STABLE boxes. >> >> I'm playing around a bit with ipfw and have not found a way to replicate >> PF's *per-rule* custom session lifetimes. >> >> Anyone's got anything on the subject ? ;) > > Is this about dynamic rules? Because looking at ipfw(8) you can only set that > globally via the net.inet.ip.fw.dyn_* sysctls. From the manual: > > Dynamic rules expire after some time, which depends on the status of the > flow and the setting of some sysctl variables. See Section SYSCTL > VARIABLES for more details. For TCP sessions, dynamic rules can be > instructed to periodically send keepalive packets to refresh the state of > the rule when it is about to expire. > Aye, that is my actual problem, a global timer as opposed to PF's per-rule capability. I understand that is an edge case, however that is one that strongly prevents the use of ipfw in PF's stead. For example, we use very aggressive timers on PF to prevent resource and state exhaustion attacks, however for some protocols we use slightly more permissive timers. Say our nginx client body timeout is 20s, I'll set us up a tcp.established timer of 22-24s on the HTTP/HTTPS rules. However, I'll stick to a regular 10s on our other rules. I'm afraid I shan't be able to do that with ipfw, killing any plans of moving to it.