From owner-freebsd-questions@FreeBSD.ORG Tue Aug 26 08:48:44 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EE9616A4BF for ; Tue, 26 Aug 2003 08:48:44 -0700 (PDT) Received: from perrin.nxad.com (internal.ext.nxad.com [69.1.70.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4918D43FBF for ; Tue, 26 Aug 2003 08:48:44 -0700 (PDT) (envelope-from sean@nxad.com) Received: by perrin.nxad.com (Postfix, from userid 1001) id AB8E620F00; Tue, 26 Aug 2003 08:48:40 -0700 (PDT) Date: Tue, 26 Aug 2003 08:48:40 -0700 From: Sean Chittenden To: questions@FreeBSD.org Message-ID: <20030826154840.GA32088@perrin.nxad.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: finger seanc@FreeBSD.org X-PGP-Fingerprint: 3849 3760 1AFE 7B17 11A0 83A6 DD99 E31F BC84 B341 X-Web-Homepage: http://sean.chittenden.org/ User-Agent: Mutt/1.5.4i Subject: ipfilter per rule ttl's not working? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2003 15:48:44 -0000 Since ipf doesn't send keep alives to refresh its connections and on our Intranet server that gets modest www traffic, how can I run with reasonably low/sane TTLs for most of our rules, but have a different TTL for ssh traffic? The documentation suggests that I can do this: filter-rule = [ insert ] action in-out [ options ] [ tos ] [ ttl ] [ proto ] [ ip ] [ group ]. ttl = "ttl" decnumber . But in practice, I think that the feature is unable to correctly identify a valid number when it sees one. >From ipf.rules: pass in quick on fxp1 ttl 604800 proto tcp from any to 192.168.1.0/24 port = 22 flags S keep state keep frags # ipf -Fa -f /etc/ipf.rules 693: invalid ttl (604800) :-/ One would think that 604800 would qualify as a decnumber. Am I missing something or is this a documented non-feature? -sc -- Sean Chittenden