From owner-freebsd-net@freebsd.org Wed Oct 7 14:43:39 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 E53B99D0194 for ; Wed, 7 Oct 2015 14:43:39 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E799B37 for ; Wed, 7 Oct 2015 14:43:39 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1444229015; l=3388; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=5c3gqJZxYHy1PzxRSTI9tTzNyZ0OpaNpc02Uz5XbKk8=; b=HJr9tav45Fa9jfuSc47rh7TSDfTQzU7zSZCy4wxhehBhL5UscJr38NUH7CYoY2srs8i Sb2n71nbUkQCg4aTRoR6uDx9xD6+1JLLUYUBRzKpeTqEpgGcXbQ8mnzH3NdZo4P0nQKpI etnsoCqMIaNfCxmxeYSEDpp/gVYpWMpVLj4= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhToX1IWHkW4X7v2ImaU2BqdKiuqxheHHhTLx X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb032267.virtua.com.br [187.3.34.103]) by smtp.strato.de (RZmta 37.13 DYNA|AUTH) with ESMTPSA id 402a43r97EhX52T (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Wed, 7 Oct 2015 16:43:33 +0200 (CEST) Received: from [192.168.222.67] (unknown [192.168.222.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 1C19C14B90549; Wed, 7 Oct 2015 11:43:30 -0300 (BRT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) Subject: Re: Struggling with IPFW on CURRENT From: "Dr. Rolf Jansen" In-Reply-To: <1444228604.4174170.403845001.7FAB35BB@webmail.messagingengine.com> Date: Wed, 7 Oct 2015 11:43:28 -0300 Cc: Guido Falsi , freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <242ED31C-C8C1-403C-8676-42DA2F256134@obsigna.com> References: <1444226262.4164898.403785985.524883DA@webmail.messagingengine.com> <56152CCD.3010302@madpilot.net> <1444228604.4174170.403845001.7FAB35BB@webmail.messagingengine.com> To: Mark Felder X-Mailer: Apple Mail (2.3094) 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:43:40 -0000 > Am 07.10.2015 um 11:36 schrieb Mark Felder : > On Wed, Oct 7, 2015, at 09:31, Guido Falsi wrote: >> On 10/07/15 15:57, Mark Felder wrote: >>> Hi all, >>>=20 >>> 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.... >>=20 >> My experience with ipfw is almost exclusively on RELEASE, but I don't >> think that much has changed in the rules syntax. >>=20 >>>=20 >>> Problems I'm running into: >>>=20 >>> * 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. >>=20 >> I'm sorry but I have made no tests with IPv6, so I can't help you on >> this one. >>=20 >>=20 >> I suspect you should also investigate using sysctl >> net.inet.ip.fw.one_pass=3D0. The ruleset below seems to require it in = a >> few places. >>=20 >>>=20 >>> * TCP sessions seem to be killed every ~300s >>=20 >> sysctl net.inet.ip.fw.dyn_ack_lifetime=3D >>=20 >> default is 300. >>=20 >=20 > These are active TCP sessions though... like IRC and SSH... But again, > probably related to one_pass. >=20 >>>=20 >>> * "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... >>=20 >> I suspect this is related to one pass above. >>=20 >>>=20 >>> * 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. >>=20 >> It does only for stateful rules, with keep-state, which you are = using. >> Which rules are failing to do that? >>=20 >=20 > I don't have any in the provided example, but noticed it when > experimenting. >=20 >>>=20 >>> * 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... >>=20 >> As above, if I remember correctly this setup requires one_pass=3D1 to >> work, I'm not completely sure this is your problem though. I think = it's >> worth a try. >>=20 >=20 > I'll give it a try. Hopefully this will be successful. You definitely need net.inet.ip.fw.one_pass=3D0 for statefule IPFW+NAT = for the IPv4 traffic. IPv6 does not pass NAT anyway and is not affected. I assume, that you have gateway_enable=3D"YES" and = ipv6_gateway_enable=3D"YES" in your /etc/rc.conf =E2=80=94 sometimes = this becomes forgotten. Best regards Rolf