From owner-freebsd-ipfw@freebsd.org Wed Mar 9 17:48:11 2016 Return-Path: Delivered-To: freebsd-ipfw@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 565C2AC914C for ; Wed, 9 Mar 2016 17:48:11 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.kissl.de (host64.kissl.de [213.239.241.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.shmhost.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1EFF91C2; Wed, 9 Mar 2016 17:48:10 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from francos-mbp.lastsummer.de (ipservice-092-217-228-193.092.217.pools.vodafone-ip.de [92.217.228.193]) (Authenticated sender: web104p1) by host64.kissl.de (Postfix) with ESMTPSA id 471256A60A; Wed, 9 Mar 2016 18:48:07 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: ipwf dummynet vs. kernel NAT and firewall rules From: Franco Fichtner In-Reply-To: <201603091733.u29HX05o011028@gw.catspoiler.org> Date: Wed, 9 Mar 2016 18:48:06 +0100 Cc: freebsd-ipfw@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <201603091733.u29HX05o011028@gw.catspoiler.org> To: Don Lewis X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.99 at host64.kissl.de X-Virus-Status: Clean X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 17:48:11 -0000 Hi Don, If you mean pf(4)-based NAT, there is a patch that originates from m0n0wall that handles the transition. We're using it in OPNsense for that reason. Here is the patch for 10.x, maybe that is what you're looking for: https://github.com/fichtner/freebsd/commit/975130903f.patch We would very much like to upstream this eventually, but are not sure what is needed (on/off switch via sysctl(8) was discussed internally but could be crude). It seems useful to have in some instances. Combining ipfw(4) and pf(4) has proven to be tricky, where even execution order of both of them matters in pfil(9). Cheers, Franco > On 09 Mar 2016, at 6:32 PM, Don Lewis wrote: > > I'm trying to add FQ-CoDEL AQM to my FreeBSD 10 firewall box using this > patch: , but I'm > running into a problem that I think is caused by an interaction between > in-kernel NAT and dummynet. I've set up two dummynet pipe/sched/queue > instances using example 3.3a from this document > with the > appropriate bandwidths, but otherwise default tunings to shape both > inbound and outbound traffic. My inside network is a /24 and I have an > external /29 (ext/29) network that I don't want to rate limit. My > outside network interface is re0. I'm using the /etc/rc.firewall > "simple" firewall configuration. > > The problem that I'm having crops up when I actually try to add the > firewall rules to select the traffic that I want to rate limit. The > first rule in the list is: > 100 allow ip from any to any via lo0 > The second rule is numbered 200 and is first anti-spoofing rule. If > I add *either* of these two rules, then I'm no longer able to > communicate between hosts on my internal network and the rest of the > world: > > ipfw 110 add queue 1 ip from not ext/29 to any in recv re0 > ipfw 120 add queue 2 ip from any to not ext/29 out xmit re0 > > It seems like the inbound rule should be early in the rule list so that > any inbound traffic that gets dropped by the firewall rules gets counted > even if it is dropped by later rules. It also seems like the outbound > rule needs to be before any allow rules since an allow rule would skip > the remaining rules and would not count that traffic. Unfortunately the > ipfw documentation doesn't really describe the interaction between > dummynet, NAT, and other firewall rules. > > Unfortunately this is a live system, so it is difficult to do controlled > experiments and look at the ipfw counters to see where things might be > going into the weeds ... > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >