From owner-freebsd-net@freebsd.org Wed Oct 7 14:36:46 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 C56DD9D1BDA for ; Wed, 7 Oct 2015 14:36:46 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 9C3DF6A3 for ; Wed, 7 Oct 2015 14:36:46 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5F6A1217C5 for ; Wed, 7 Oct 2015 10:36:45 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Wed, 07 Oct 2015 10:36:45 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=5Nh+s1UtZ8t0AOG lAu9KhxaXquE=; b=hldQz8SXSzfb7BePb7Q8VoYnhiZTHORO4f7phvQvmQlYKja C0wIktJlrNYAqM7XTDjq9APT82XJxxCffACWoeis2oIbTUfhvf/w9Gji1ZgeHwzd vK+5hs4PHlE7BQL6595DCZMS559lcksy8AWCM3661tSPCUMCYGZ8O9Lvzqyk= Received: by web3.nyi.internal (Postfix, from userid 99) id 3C62C10D4A9; Wed, 7 Oct 2015 10:36:44 -0400 (EDT) Message-Id: <1444228604.4174170.403845001.7FAB35BB@webmail.messagingengine.com> X-Sasl-Enc: v0cPhvB4vcGHddUeQwq+US3Z8k7MTcCUmyFNfvwZ/GnT 1444228604 From: Mark Felder To: Guido Falsi , freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-bd1c65cb In-Reply-To: <56152CCD.3010302@madpilot.net> References: <1444226262.4164898.403785985.524883DA@webmail.messagingengine.com> <56152CCD.3010302@madpilot.net> Subject: Re: Struggling with IPFW on CURRENT Date: Wed, 07 Oct 2015 09:36:44 -0500 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:36:47 -0000 On Wed, Oct 7, 2015, at 09:31, Guido Falsi wrote: > 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. > These are active TCP sessions though... like IRC and SSH... But again, probably related to one_pass. > > > > * "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? > I don't have any in the provided example, but noticed it when experimenting. > > > > * 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. > > Hope this helps. > > -- > Guido Falsi 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. -- Mark Felder ports-secteam member feld@FreeBSD.org