From owner-freebsd-net@freebsd.org Wed Oct 7 15:01:01 2015 Return-Path: Delivered-To: freebsd-net@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 ACDEC9D0D0E for ; Wed, 7 Oct 2015 15:01:01 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F13667E; Wed, 7 Oct 2015 15:01:00 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3nWJky137jzZsp; Wed, 7 Oct 2015 17:00:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject:received:received; s=mail; t= 1444230056; x=1446044457; bh=4RP/962Zr+68TdpZjAcSFTXY76EC8gVPWbW Lcvc3cr0=; b=PqjHdSWcd0iywsmr1KGY1CdAAjlF8V++kK1BV8t2YegKp//3AOL oltkOHzin9PiU8to18Nqk53V2mQGhIgQ0an0dJ3H3OHcJiGmw7p4N4cPdgM0Z+3t tcj5/yFdRWruQ/Y4uWkmKSdOFdN4f1UpZWjXDM/aDN+xJUASuRADXHQI= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id Hurb3ck17_iv; Wed, 7 Oct 2015 17:00:56 +0200 (CEST) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Wed, 7 Oct 2015 17:00:56 +0200 (CEST) Subject: Re: Struggling with IPFW on CURRENT To: Mark Felder , freebsd-net@freebsd.org References: <1444226262.4164898.403785985.524883DA@webmail.messagingengine.com> <56152CCD.3010302@madpilot.net> <1444228604.4174170.403845001.7FAB35BB@webmail.messagingengine.com> From: Guido Falsi Message-ID: <561533A7.2010501@madpilot.net> Date: Wed, 7 Oct 2015 17:00:55 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1444228604.4174170.403845001.7FAB35BB@webmail.messagingengine.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 07 Oct 2015 15:01:01 -0000 On 10/07/15 16:36, Mark Felder wrote: >> I suspect you should also investigate using sysctl >> net.inet.ip.fw.one_pass=0. The ruleset below seems to require it in a >> few places. >> >>> >>> * TCP sessions seem to be killed every ~300s >> >> sysctl net.inet.ip.fw.dyn_ack_lifetime= >> >> default is 300. >> > > These are active TCP sessions though... like IRC and SSH... But again, > probably related to one_pass. I misinterpreted that point. But the fact that they get killed after a time so similar to the timeout looks suspicious :) >>> * Does IPFW not track outbound traffic to allow it back through -- >>> related/established ? I have trouble blocking inbound traffic without >>> blocking originated/outbound traffic because the firewall blocks the >>> return packets. >> >> It does only for stateful rules, with keep-state, which you are using. >> Which rules are failing to do that? >> > > I don't have any in the provided example, but noticed it when > experimenting. I see, well unstateful rules keep no information, so you need separate rules for inbound and outbound traffic. > >>> >>> * Port forwarding is failingl, probably due to the issues with the "in >>> via" that I'm experiencing. Research says once I have the redirect_port >>> configured I should be good to go as long as I match the traffic and >>> skip to the NAT rule. Skip rules don't stop processing, so it should hit >>> the next rule which is the last rule in my config -- allow from any to >>> any. (Documentation for in-kernel NAT is nonexistent and really needs >>> help). The rule 425 below should be working, but logs show that rule is >>> ignored and it's being blocked at 550. Comment out 550 and it works... >> >> As above, if I remember correctly this setup requires one_pass=1 to >> work, I'm not completely sure this is your problem though. I think it's >> worth a try. >> > > I'll give it a try. Hopefully this will be successful. > >> >> Please note that my structure is just an example, there are many other >> ways to organize your firewall. I have a setup that uses many stateful >> rules, but some people prefer stateless firewalling, which requires >> rules for both inbound and outbound traffic. > > Yeah, I could do stateless and require both inbound and outbound rules > but that's tedious and I hate the idea of having to toy with my firewall > every time I want to connect to something new/unusual. > I agree, that's why I also use lots of stateful rules. BTW ping and traceroute from natted hosts could require some special care too work correctly. But your rules look quite permissive so maybe those will work OOB. -- Guido Falsi