From owner-freebsd-ipfw@freebsd.org Mon Jun 20 12:50:59 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 4C4C7AC451D for ; Mon, 20 Jun 2016 12:50:59 +0000 (UTC) (envelope-from info@rickvanderzwet.nl) Received: from pzwet.vanderzwet.net (pzwet.vanderzwet.net [IPv6:2a01:4f8:190:8221::1:1]) by mx1.freebsd.org (Postfix) with ESMTP id 0EC8E2976 for ; Mon, 20 Jun 2016 12:50:58 +0000 (UTC) (envelope-from info@rickvanderzwet.nl) Received: from rvdzwet-asus.vanderzwet.net (5ED2849E.cm-7-3c.dynamic.ziggo.nl [94.210.132.158]) by pzwet.vanderzwet.net (Postfix) with ESMTPSA id 7FDE611124A3 for ; Mon, 20 Jun 2016 12:50:49 +0000 (UTC) To: freebsd-ipfw@freebsd.org From: Rick van der Zwet Subject: Dummynet combined upload en download bandwidth limit per client Message-ID: <0ed020c5-aa22-4c33-216f-a6dc52720c68@rickvanderzwet.nl> Date: Mon, 20 Jun 2016 14:50:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 12:50:59 -0000 Hi Folks, I would like to be able to limit bandwidth (upload + download) per client using dummynet. Yet I fail to create dynamic pipes which matches both upload and download at the same time. re2 is the interface on which the the clients are connected in network 192.168.0.0/24. I am able to limit download (300Mbit/s) with dynamic pipes using: ${fwcmd} pipe 1 config bw 300Kbit/s mask dst-ip 0xffffffff ${fwcmd} add 60000 pipe 1 ip from not me to 192.168.0.0/24 via re2 out I am able to limit upload (300Mbit/s) with dynamic pipes using: ${fwcmd} pipe 1 config bw 300Kbit/s mask src-ip 0xffffffff ${fwcmd} add 60000 pipe 1 ip from 192.168.0.0/24 to not me via re2 in I am able to limit upload+download (total 300Mbit/s) for single (192.168.0.10) IP using: ${fwcmd} pipe 1 config bw 300Kbit/s ${fwcmd} add 60000 pipe 1 ip from not me to 192.168.0.10/32 via re2 out ${fwcmd} add 60000 pipe 1 ip from 192.168.0.10/32 to not me via re2 in Yet duplicating the last one for all client IPs addresses 'feels' wrong and is a bit verbose. Am I able to limit upload+download bandwidth for multiple IPs without pre-creation of 1 pipe per client and the required rules? Best regards, /Rick From owner-freebsd-ipfw@freebsd.org Mon Jun 20 14:00:02 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 80248A784AA for ; Mon, 20 Jun 2016 14:00:02 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 608E72AC7; Mon, 20 Jun 2016 14:00:02 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-242-176.lns20.per4.internode.on.net [121.45.242.176]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u5KDxrYa088152 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 20 Jun 2016 06:59:56 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: Ian Smith References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> Cc: "Andrey V. Elsukov" , lev@freebsd.org, "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org From: Julian Elischer Message-ID: Date: Mon, 20 Jun 2016 21:59:48 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160616005016.A15883@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 14:00:02 -0000 On 16/06/2016 12:11 AM, Ian Smith wrote: > On Mon, 13 Jun 2016 23:18:24 +0800, Julian Elischer wrote: > > On 10/06/2016 5:11 AM, Lev Serebryakov wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA512 > > > > > > On 07.06.2016 00:53, Andrey V. Elsukov wrote: > > > > > > > looking at provided description and examples, seems the main task > > > > you want to solve is problem with NAT. But from my point of view, > > > > you are trying to solve it in a easy way wrongly using existing > > > > methods. > > > It is was initial driver for this patch, yes, but, please, read > > > subject (? is mistype, of course, it is closing "). > > > > > > Current set of primitives, dealing with state, is terribly wrong, > > > IMHO. "keep-state" which trigger (any!) state check alone is awuful, > > > and complete "keep-state / check-state" pair is ugly hack. It is like > > > CISC vs RISC, actually. > > > > > > New primitives are ORTHOGONAL. Each one solves one and only one > > > well-defined task, state creation, state checking and command > > > execution are well-separated. IMHO, "keep-state" in it current form > > > should be killed with fire. Yes, I understand about backward > > > compatibility and POLA, so I don't propose to really remove it, but, > > > IMHO, new set is much, much better. > > Lev, is there any chance you and Andrey can work together here? At the > moment we seem to have two 'competing' models. Can they be melded at > all? Or can you live with adding new opcodes on top of Andrey's named > states? (Feel free to tell me that this is none of my business ..) yes, please.. > > In writing complicated automatically generated firewalls, > > I've wanted the following capacities: > > 1/ one state table for one part of the flow and another for a different > > part... e.g. a different table for "inside" nat to "outside" nat.. > > Isn't one table with distinct flow-or-whatever names for matching not > sufficient for this purpose? Wouldn't that also be faster than having > to consult multiple distinct tables? if you name table entries then you effectively have different tables, but yes I was mistaken in how it was being done. I had assumed a separate table > > In the end those are details the user doesn't need to know about .. but > ze does need to comprehend the terms conveying the ideas. > > > also a different table for the inside interface to the outside interface.. > > just because you allow a flow at one interface doesn't mean you want it to be > > allowed through a different one. > > Sure, so couldn't you have, say, 'inbound_outside', 'inbound_inside', > 'outbound_outside' and 'outbound_inside', 'from_dmz' or whatever to > distinguish multiple flows? > > Why doesn't 'flowname' sound right to describe what you call 'flows'? multiple flows can end up in the same table/name a flow to me is some set of packets that relate to each other in source, destination and sequence. you could almost say that each pair of sockets defines a flow. Others probably have different definitions.. One could even say that in the context of ipfw, any set of packets that can be discriminated by a set of rules can be a flow. > > > 2/ The ability to specifically add a flow's state rule to a table, without > > EVERY OTHER FLOW hitting a 'check-state' at that point. If I select s > > particular flow , then I do not want other flows affected. just that flow > > should be affected. > > Isn't that the case with Andrey's code at the moment, if you specify a > name on that keep-state rule, only that - erm - flow would be checked > and not other flows (including 'default' where added by unnamed rules)? no. but it is the case with Lev's patch (and Andrey's matching effort) > > Can I assume that if this is the first keep-state|limit for one flowname > then an implicit check-state would check that flow only, finding none? I don't know. currently the selector part of the rule doesn't distinguish who does a check-state. I'm guessing he finds the label and uses it but I don't know. > > Similarly, if I'm grokking this at all right, then only a check-state > (or another keep-state or limit encountered) with that same name will > match existing states having that same name? Issue 2/ solved or not? Issue 2 is mostly solved for many cases. > > I hope you can see my concern that this be easily described in ipfw(8) > so people without high level of expertise can easily see how it works. > > I'll have some more suggestions re description along the way, but after > seeing clear agreement that the proposed model/s cover the usage cases > described (somewhat), and where not, what more needs doing to make it > acceptable as a next step, if not entirely ideal for every case .. > > To that end, I'll leave wishes 3/ and 4/ well alone .. as usual, FWIW > > cheers, Ian > > > 3/ the ability to select a completley different firewall for a differnent > > interface.. this can be simulated at the moment. but it'd be nice to be able > > to specify a entry pont into the table or a separate table per interface.. > > ipfw interface xn0 in enter 5000 or something. > > or maybe ipfw interface firewall 3 > > 4/ the ability to have variables and set and test them. We ALMOST have that > > with tags . > > i] variables would hav eone of several scopes: > > a) a single transit.. you might set some flag at rule 40 and branch on it > > at rule 4000, but a separate packet would ahv ea different instance. > > b) per flow.. assigned at creation of the dynamic rule and avaliable at > > any time after a packet has been associated with that flow. > > c) global > > ii] branching on values is possible. > > there are others I've wanted (and forgotten) but that's the wish-list I have > > at the moment. > _______________________________________________ > 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" > From owner-freebsd-ipfw@freebsd.org Mon Jun 20 19:06:28 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 0351EAC487D for ; Mon, 20 Jun 2016 19:06:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 E734B2831 for ; Mon, 20 Jun 2016 19:06:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u5KJ6Rru024068 for ; Mon, 20 Jun 2016 19:06:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 210408] Problem with outgoing traffic using ipfw and kernel nat originated from local address Date: Mon, 20 Jun 2016 19:06:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 19:06:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210408 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-ipfw@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ipfw@freebsd.org Wed Jun 22 08:05:21 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 995D6B0382B for ; Wed, 22 Jun 2016 08:05:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 88E602561 for ; Wed, 22 Jun 2016 08:05:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u5M85LfE090103 for ; Wed, 22 Jun 2016 08:05:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 210408] Problem with outgoing traffic using ipfw and kernel nat originated from local address Date: Wed, 22 Jun 2016 08:05:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: smithi@nimnet.asn.au X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 08:05:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210408 smithi@nimnet.asn.au changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |smithi@nimnet.asn.au --- Comment #1 from smithi@nimnet.asn.au --- >From ipfw(8), second last paragraph: " Due to the architecture of libalias(3), ipfw nat is not compatible with the TCP segmentation offloading (TSO). Thus, to reliably nat your net- work traffic, please disable TSO on your NICs using ifconfig(8)." I don't know about RXCSUM & TXCSUM in this context, but NAT is only for IPv4 - make sure your NAT rules only apply to ipv4 packets specifically - and you certainly need to turn TSO4 off when using either kernel NAT or natd(8), both of which use libalias(3). --=20 You are receiving this mail because: You are the assignee for the bug.=