Date: Wed, 7 Oct 2015 11:43:28 -0300 From: "Dr. Rolf Jansen" <rj@obsigna.com> To: Mark Felder <feld@FreeBSD.org> Cc: Guido Falsi <mad@madpilot.net>, freebsd-net@freebsd.org Subject: Re: Struggling with IPFW on CURRENT Message-ID: <242ED31C-C8C1-403C-8676-42DA2F256134@obsigna.com> In-Reply-To: <1444228604.4174170.403845001.7FAB35BB@webmail.messagingengine.com> References: <1444226262.4164898.403785985.524883DA@webmail.messagingengine.com> <56152CCD.3010302@madpilot.net> <1444228604.4174170.403845001.7FAB35BB@webmail.messagingengine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 07.10.2015 um 11:36 schrieb Mark Felder <feld@FreeBSD.org>: > 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<seconds> >>=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?242ED31C-C8C1-403C-8676-42DA2F256134>