From owner-freebsd-net@freebsd.org Wed Oct 7 14:31:53 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 951849D194F for ; Wed, 7 Oct 2015 14:31:53 +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 20FCB182; Wed, 7 Oct 2015 14:31:52 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3nWJ5C5SXXzZsp; Wed, 7 Oct 2015 16:31:43 +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= 1444228302; x=1446042703; bh=fRnpXa9lnASEHv9KQp7f3042EbEnY8obLI/ TEgeWSAY=; b=fzRfZAsUKo4nBmjBxGp9gc1GkZrbuS6jarpNRhkEFPZDfRkhcbM Dbdx6v5cR2fUGfXYKurDHeHyqhQm3tDC8MY7IBJUK0PZi3ujDWUQXlJJH2bQCNxQ Dg76T1Bu/dqvzeEFpz7voNxDor566oh70Xy+/+asCz3iZUq18HhflM5Y= 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 bmZrML-_quek; Wed, 7 Oct 2015 16:31:42 +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 16:31:41 +0200 (CEST) Subject: Re: Struggling with IPFW on CURRENT To: Mark Felder , freebsd-net@freebsd.org References: <1444226262.4164898.403785985.524883DA@webmail.messagingengine.com> From: Guido Falsi Message-ID: <56152CCD.3010302@madpilot.net> Date: Wed, 7 Oct 2015 16:31:41 +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: <1444226262.4164898.403785985.524883DA@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 14:31:53 -0000 On 10/07/15 15:57, Mark Felder wrote: > Hi all, > > I've only used IPFW in the past for the most basic of tasks. I'd like to > use it with in-kernel NAT protecting both v4 and v6 and add > dummynet/pipe later, but I have to get the basic working first. I'm > either overlooking something obvious or there's a major issue. Has there > been work in CURRENT? I haven't tried on any RELEASE.... My experience with ipfw is almost exclusively on RELEASE, but I don't think that much has changed in the rules syntax. > > Problems I'm running into: > > * Inbound v4 traffic to the firewall is blocked, but inbound v6 traffic > to firewall and hosts behind it are not. Both v4 and v6 should be > handled by keywords: tcp, udp, ip, me. I'm sorry but I have made no tests with IPv6, so I can't help you on this one. 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. > > * "in via $pif" doesn't seem to work. ex: block icmp from internet to > $pif fails to do anything. However, "block out via $pif" blocks it... I suspect this is related to one pass above. > > * 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? > > * 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. 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. Hope this helps. -- Guido Falsi