From owner-freebsd-ipfw@freebsd.org Sun Jul 26 08:52:27 2015 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 CDB7C9A3FCF for ; Sun, 26 Jul 2015 08:52:27 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37E3EBA for ; Sun, 26 Jul 2015 08:52:26 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t6Q8iYTY019246; Sun, 26 Jul 2015 18:44:37 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 26 Jul 2015 18:44:34 +1000 (EST) From: Ian Smith To: hiren panchasara cc: freebsd-ipfw@freebsd.org Subject: Re: Traffic not going through dummynet In-Reply-To: <20150720040653.GV38517@strugglingcoder.info> Message-ID: <20150726181056.C17327@sola.nimnet.asn.au> References: <20150718194020.GQ38517@strugglingcoder.info> <20150718202818.GR38517@strugglingcoder.info> <20150720040653.GV38517@strugglingcoder.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 08:52:27 -0000 On Sun, 19 Jul 2015 21:05:53 -0700, hiren panchasara wrote: > Bah. > > So I removed ipfw and dummynet from kernconf and loaded them manually > after machine came up and it worked as expected. In your previous post, you'd said you were using 11-current, and: > And GENERIC has: > options IPFIREWALL > options DUMMYNET > options HZ=1000 Are you sure this was a 11 GENERIC kernconf? Those options haven't been in GENERIC for ages (if ever?), though they haven't needed to be since (perhaps) 8.0. I guess people just follow the handbook :( > Looks like some ordering issue between ipfw and dummynet. Fwiw, for > working setup, kldstat shows: > > 13 2 0xffffffff81e21000 21490 ipfw.ko > 14 1 0xffffffff81e43000 d0f6 dummynet.ko Indeed. If you load ipfw and dummynet by the usual means, being firewall_enable=YES and dummynet_enable=YES in rc.conf, you'll notice that /etc/rc.d/ipfw, in ipfw_prestart, loads dummynet if enabled, and natd and/or firewall_nat if enabled, in that order. The downside to doing that is that you have to have specified a type for rc.firewall or pointed to a custom ruleset so it's sane on startup. Regarding the related(?) Bug 201488 - dummynet appears broken in 10.0-RELEASE and onwards (can't traffic shape on bridges) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201488 it does seem likely to be the same issue as you noted. Did you ever hear back from James Rice (for whom I seem to have seen no other messages for an email address) as to whether your advice about loading these in the other order helped there? As to whether this is a regression, or it would have ever worked loading dummynet and then ipfw, I don't know, but I have a vague feeling that I've seen other issues regarding loading a module that's already in kernel in recent times .. sorry I can't be any more exact. Maybe dummynet needs a check that ipfw is loaded before starting? cheers, Ian From owner-freebsd-ipfw@freebsd.org Tue Jul 28 05:30:44 2015 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 302CB9ACA1C for ; Tue, 28 Jul 2015 05:30:44 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 73DB8BD6; Tue, 28 Jul 2015 05:30:42 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t6S5UbN6010082; Tue, 28 Jul 2015 15:30:37 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 28 Jul 2015 15:30:37 +1000 (EST) From: Ian Smith To: Lev Serebryakov cc: freebsd-ipfw@freebsd.org Subject: Re: keep-state and in-kernel NAT exposes local ip on external interface In-Reply-To: <5594395D.6050103@FreeBSD.org> Message-ID: <20150728150845.V17327@sola.nimnet.asn.au> References: <1435692039.18121.12.camel@yahoo.com> <5594395D.6050103@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 05:30:44 -0000 Way back on Wed, 1 Jul 2015 22:02:53 +0300, Lev Serebryakov wrote: > On 30.06.2015 22:20, Georgios Amanakis via freebsd-ipfw wrote: > > It is good example for my changes :) All this "skipto / keep-state" > magic is not understandable. Indeed. So all we're waiting for, Lev, is some simple usage examples of how things should be done with your new stateful operators, especially when combining stateful rules with NAT. Please see what you can do .. I know it's clear to you, but I for one cannot get my head around these without a couple of examples, roughly suitable for inclusion in ipfw(8) EXAMPLES section. Rough illustrations would do fine at first. In the problems shown lately, including the one below (harder to read with the quoting wrapped like that!) it seems the problem of keepalives being issued using the internal address would not occur if keep-state was only applied _after_ NAT, only on the already-translated source address, but like you and apparently many others, I find these rulesets very difficult to follow in terms of different possible flows. cheers, Ian > > On FreeBSD 10.1p13 with two interfaces em0(internet) and em1(lan) I > > can fish (tcpdump)packets on em0 which have escaped the in-kernel > > NAT and have as source address an IP on the LAN. > > > > This should not happen and I can confirm that with pf this is not > > the case. I have the following ipfw rules: > > > > nat: ipfw nat 123 config ip xxx.xxx.xxx.xxx same_ports reset > > > > 00100 reass ip from any to any in 00200 allow ip from any to any > > via lo0 00300 allow ip from any to any via em1 00400 nat 123 ip > > from any to any in recv em0 00500 check-state 00600 skipto 24000 ip > > from any to me dst-port 80,443,22,500,4500,1194,993,8112 in recv > > em0 keep-state 00700 skipto 24000 ip from any to any out xmit em0 > > keep-state 00800 deny log ip from any to any 24000 nat 123 ip from > > any to any out xmit em0 24100 allow ip from any to any > > > > Contrary to many online tutorials, including the example of the > > handbook regarding NAT ( > > https://www.freebsd.org/doc/handbook/firewalls-ipfw.html), when > > one places the NAT rules with the opposite order (i.e. outbound > > rule first and then the inbound rule) the problem disappears. > > > > i.e. ... 00400 nat 123 ip from any to any out xmit em0 ... 24000 > > nat 123 ip from any to any in recv em0 ... > > > > Why is this happening? Any objections to reversing the order of the > > NAT rules? > - -- > // Lev Serebryakov From owner-freebsd-ipfw@freebsd.org Tue Jul 28 06:50:02 2015 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 3315D9ACC62 for ; Tue, 28 Jul 2015 06:50:02 +0000 (UTC) (envelope-from bycn82@gmail.com) Received: from mail-vn0-x22f.google.com (mail-vn0-x22f.google.com [IPv6:2607:f8b0:400c:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E250ED3A; Tue, 28 Jul 2015 06:50:01 +0000 (UTC) (envelope-from bycn82@gmail.com) Received: by vnds125 with SMTP id s125so39510240vnd.1; Mon, 27 Jul 2015 23:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NJCHuFKkV+OWbGd7rPvz1owaiKatulMkAsCFPjAdEV0=; b=HSwcarDjB792kuHnbymAS4lrEZSgqrMRSob4U+Ru+TKjFQIKN61nVnRZTgXlRWY7lG 7Z4Aso6XzrsTLqtvmBYDkcVUmpqkIt2LTEsIkbtIzA7UQKtfCwZvgt+ZA18C6R2LFj4z L7Cn7knuutNRjgJ5nG3SvKkLk6LeaMuLnxvmo1n7QhYBQvD9vzP1y8dbWYnqwHJWalTV vYar7uVzCBaDjWfxPqLziaRfv0SZG1qtMPp0rnRMbxvex9hs/gPgmAdppDp60Xcbzbwa qGYmZTXIzRzj4lFDr2D60LVOaLDa60F/OvS59urtTBKYGul8/xyVvGQ94Tt8J3jqDV/6 4MIA== MIME-Version: 1.0 X-Received: by 10.52.252.74 with SMTP id zq10mr40413976vdc.18.1438066200555; Mon, 27 Jul 2015 23:50:00 -0700 (PDT) Received: by 10.31.174.6 with HTTP; Mon, 27 Jul 2015 23:50:00 -0700 (PDT) In-Reply-To: <20150728150845.V17327@sola.nimnet.asn.au> References: <1435692039.18121.12.camel@yahoo.com> <5594395D.6050103@FreeBSD.org> <20150728150845.V17327@sola.nimnet.asn.au> Date: Tue, 28 Jul 2015 14:50:00 +0800 Message-ID: Subject: Re: keep-state and in-kernel NAT exposes local ip on external interface From: bycn82 To: Ian Smith Cc: Lev Serebryakov , "freebsd-ipfw@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 06:50:02 -0000 for me. i am totally dont understand all these. waiting dor example as well On Tuesday, July 28, 2015, Ian Smith wrote: > Way back on Wed, 1 Jul 2015 22:02:53 +0300, Lev Serebryakov wrote: > > On 30.06.2015 22:20, Georgios Amanakis via freebsd-ipfw wrote: > > > > It is good example for my changes :) All this "skipto / keep-state" > > magic is not understandable. > > Indeed. So all we're waiting for, Lev, is some simple usage examples of > how things should be done with your new stateful operators, especially > when combining stateful rules with NAT. Please see what you can do .. > > I know it's clear to you, but I for one cannot get my head around these > without a couple of examples, roughly suitable for inclusion in ipfw(8) > EXAMPLES section. Rough illustrations would do fine at first. > > In the problems shown lately, including the one below (harder to read > with the quoting wrapped like that!) it seems the problem of keepalives > being issued using the internal address would not occur if keep-state > was only applied _after_ NAT, only on the already-translated source > address, but like you and apparently many others, I find these rulesets > very difficult to follow in terms of different possible flows. > > cheers, Ian > > > > On FreeBSD 10.1p13 with two interfaces em0(internet) and em1(lan) I > > > can fish (tcpdump)packets on em0 which have escaped the in-kernel > > > NAT and have as source address an IP on the LAN. > > > > > > This should not happen and I can confirm that with pf this is not > > > the case. I have the following ipfw rules: > > > > > > nat: ipfw nat 123 config ip xxx.xxx.xxx.xxx same_ports reset > > > > > > 00100 reass ip from any to any in 00200 allow ip from any to any > > > via lo0 00300 allow ip from any to any via em1 00400 nat 123 ip > > > from any to any in recv em0 00500 check-state 00600 skipto 24000 ip > > > from any to me dst-port 80,443,22,500,4500,1194,993,8112 in recv > > > em0 keep-state 00700 skipto 24000 ip from any to any out xmit em0 > > > keep-state 00800 deny log ip from any to any 24000 nat 123 ip from > > > any to any out xmit em0 24100 allow ip from any to any > > > > > > Contrary to many online tutorials, including the example of the > > > handbook regarding NAT ( > > > https://www.freebsd.org/doc/handbook/firewalls-ipfw.html), when > > > one places the NAT rules with the opposite order (i.e. outbound > > > rule first and then the inbound rule) the problem disappears. > > > > > > i.e. ... 00400 nat 123 ip from any to any out xmit em0 ... 24000 > > > nat 123 ip from any to any in recv em0 ... > > > > > > Why is this happening? Any objections to reversing the order of the > > > NAT rules? > > > - -- > > // Lev Serebryakov > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org > " > From owner-freebsd-ipfw@freebsd.org Tue Jul 28 19:43:18 2015 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 EEFFF9ADC8F for ; Tue, 28 Jul 2015 19:43:17 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 77F101F76 for ; Tue, 28 Jul 2015 19:43:17 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id B3ED92B07; Tue, 28 Jul 2015 22:43:15 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: keep-state and in-kernel NAT exposes local ip on external interface References: <1435692039.18121.12.camel@yahoo.com> <5594395D.6050103@FreeBSD.org> <20150728150845.V17327@sola.nimnet.asn.au> To: Ian Smith Cc: freebsd-ipfw@freebsd.org From: Lev Serebryakov Organization: FreeBSD Message-ID: <55B7DB52.7010504@FreeBSD.org> Date: Tue, 28 Jul 2015 22:43:14 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150728150845.V17327@sola.nimnet.asn.au> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 19:43:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 28.07.2015 08:30, Ian Smith wrote: I have global lack of any spare time (and all my FreeBSD activity is only a hobby) for last ~2 months. I see the end of this unfortunate state of affairs in near future and I remember about these examples. > Way back on Wed, 1 Jul 2015 22:02:53 +0300, Lev Serebryakov wrote: >> On 30.06.2015 22:20, Georgios Amanakis via freebsd-ipfw wrote: >> >> It is good example for my changes :) All this "skipto / >> keep-state" magic is not understandable. > > Indeed. So all we're waiting for, Lev, is some simple usage > examples of how things should be done with your new stateful > operators, especially when combining stateful rules with NAT. > Please see what you can do .. > > I know it's clear to you, but I for one cannot get my head around > these without a couple of examples, roughly suitable for inclusion > in ipfw(8) EXAMPLES section. Rough illustrations would do fine at > first. > > In the problems shown lately, including the one below (harder to > read with the quoting wrapped like that!) it seems the problem of > keepalives being issued using the internal address would not occur > if keep-state was only applied _after_ NAT, only on the > already-translated source address, but like you and apparently many > others, I find these rulesets very difficult to follow in terms of > different possible flows. > > cheers, Ian > >>> On FreeBSD 10.1p13 with two interfaces em0(internet) and >>> em1(lan) I can fish (tcpdump)packets on em0 which have escaped >>> the in-kernel NAT and have as source address an IP on the LAN. >>> >>> This should not happen and I can confirm that with pf this is >>> not the case. I have the following ipfw rules: >>> >>> nat: ipfw nat 123 config ip xxx.xxx.xxx.xxx same_ports reset >>> >>> 00100 reass ip from any to any in 00200 allow ip from any to >>> any via lo0 00300 allow ip from any to any via em1 00400 nat >>> 123 ip from any to any in recv em0 00500 check-state 00600 >>> skipto 24000 ip from any to me dst-port >>> 80,443,22,500,4500,1194,993,8112 in recv em0 keep-state 00700 >>> skipto 24000 ip from any to any out xmit em0 keep-state 00800 >>> deny log ip from any to any 24000 nat 123 ip from any to any >>> out xmit em0 24100 allow ip from any to any >>> >>> Contrary to many online tutorials, including the example of the >>> handbook regarding NAT ( >>> https://www.freebsd.org/doc/handbook/firewalls-ipfw.html), >>> when one places the NAT rules with the opposite order (i.e. >>> outbound rule first and then the inbound rule) the problem >>> disappears. >>> >>> i.e. ... 00400 nat 123 ip from any to any out xmit em0 ... >>> 24000 nat 123 ip from any to any in recv em0 ... >>> >>> Why is this happening? Any objections to reversing the order of >>> the NAT rules? > >> - -- // Lev Serebryakov > - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVt9tRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePejUQAMknraIZcEVjcS+rctLZ1RUl rOgiYBI3R8LWXi8QaiMYnIqHPhI8llsKNPi/3g1eWaZcgFhOEkzZlG6Nv+EvXTYC 3U7ml35WjqOKf6q7o/HLcA3GBkFUoNTnSnwbVnrfiKdlshu2nRN+IEvWUW9Uc8Zc b2O0PKpOhdw1L8pbh8ZPNh1Sv3JyMFOoi3WWAu4kNWI+i+wYe0anKsNG9eDzI398 bRMOFXFEuM2qsjseDL9wyi2LJYhGk5kaO5fp+3NkBuqI3KFDUxlJ63Xz2E2fMUI6 y0HtHpuB6JUbSUrWIMsK0TUgGkInHwBg71pUa4N/Cv3z68fA8/V3u57JQMisoFzQ MemareZUd0Af87a9Rk+XwcV1gdVN+neavlcdRK0h58nUwJOWrF2U2bjkglvrUN2v LCXc2ietFeEkj4CgbebQLwRHLtuB6rPQSY6tknnNkoybzRyA1nZBDM+W2GTfo3ap iHz2Dtakd45njJLK5AYom/1blbpZHW1Mw0DpdV+2t3c/0UqXGITtds5dyvSGyBQN iII4K2eqOwf6QHe6i0LDc6ZcWnX64xZJbS2lzyoUlrGrbszXu2hgZLfwgN+pJ1Zd 5i+HCg2cJcZsft9hOusS4SC3LcgUly2IFLwrPZcYI4Y9zLwBfa01smLRzwza/ruT PBV3/W3B9sLMZA1/8gny =O0Et -----END PGP SIGNATURE----- From owner-freebsd-ipfw@freebsd.org Wed Jul 29 07:39:50 2015 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 47A949AB473 for ; Wed, 29 Jul 2015 07:39:50 +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 29D7A1F6A for ; Wed, 29 Jul 2015 07:39:49 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-239-102.lns20.per1.internode.on.net [121.45.239.102]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t6T7djsw058940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 29 Jul 2015 00:39:48 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: keep-state and in-kernel NAT exposes local ip on external interface To: freebsd-ipfw@freebsd.org References: <1435692039.18121.12.camel@yahoo.com> <5594395D.6050103@FreeBSD.org> <20150728150845.V17327@sola.nimnet.asn.au> <55B7DB52.7010504@FreeBSD.org> From: Julian Elischer Message-ID: <55B8833B.3030205@freebsd.org> Date: Wed, 29 Jul 2015 15:39:39 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B7DB52.7010504@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 07:39:50 -0000 On 7/29/15 3:43 AM, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 28.07.2015 08:30, Ian Smith wrote: > > I have global lack of any spare time (and all my FreeBSD activity is > only a hobby) for last ~2 months. I see the end of this unfortunate > state of affairs in near future and I remember about these examples. > >> there are some simple examples of things this patch addresses.. For example in the current code, the following (extemely simplified) set of rules will not do what you would think when you are working with a tcp session from A to B and another from C to D *which has previously been** **accepted with a keep-state at some other point in the ruleset* 10 {any action} from A to B keep-state 20 {any action} tcp from C to D because despite the fact that you are only triggering on a 'setup' packet for A to B, any rule that includes "keep-state" does a "check-state" implicitly. so the packet from C to D never gets past rule 10. the only way you can do this is to prefix rule 10 by something like 5 skipto 10 from A to B 6 skipto 11 from any to any to make sure packets that are not A to B do not hit the hidden 'check-state' . this is a very simple example and yes there are ways to get around it, but it complicates the ruleset and increases errors that reminds me I'd also like to be able to put a "not" at the front of the rule matching to negate the whole test but it doesn't seem to like that. From owner-freebsd-ipfw@freebsd.org Wed Jul 29 09:26:14 2015 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 715219AE8BF for ; Wed, 29 Jul 2015 09:26:14 +0000 (UTC) (envelope-from bycn82@gmail.com) Received: from mail-vn0-x229.google.com (mail-vn0-x229.google.com [IPv6:2607:f8b0:400c:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F17C1CE5; Wed, 29 Jul 2015 09:26:13 +0000 (UTC) (envelope-from bycn82@gmail.com) Received: by vnaa140 with SMTP id a140so1088268vna.2; Wed, 29 Jul 2015 02:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PF1Q9mZe1OXDOuWOAEJqXIv2LLQ3JzI9u8D2Miff+pU=; b=GfwryP6gPnMKzo4uqgT/gdthKqwD4l0dRp8h9OyXcOEeNO6S6WGgDYaj4oiZ049OHu CTuMzZbHTTxEzBVNunz0j0X7UOpRYZipm2ZHvooEgSZYlL7ZANts2RlzUsibTaS7n9K6 TTjvrqMou1rPAyjPVEOlis3h1bOpA8RoGQyDXoMH7LORTjpXWLijQNm/+OcoI0Ko6HYv NA8FEX2CXYVj6TnCUroGHOmshh3uPPU3gUqdZGNHL7dkbFdTKxF2coSt1JIc39ry5+37 m4rCv9YrLagUUHSR7Ifldp2i60Xq0JQW1MySzm2MLGkiriRHICsnDDauC6MfUb4ZpEzn zPwA== MIME-Version: 1.0 X-Received: by 10.52.12.103 with SMTP id x7mr50633999vdb.70.1438161972010; Wed, 29 Jul 2015 02:26:12 -0700 (PDT) Received: by 10.31.174.6 with HTTP; Wed, 29 Jul 2015 02:26:11 -0700 (PDT) In-Reply-To: <55B8833B.3030205@freebsd.org> References: <1435692039.18121.12.camel@yahoo.com> <5594395D.6050103@FreeBSD.org> <20150728150845.V17327@sola.nimnet.asn.au> <55B7DB52.7010504@FreeBSD.org> <55B8833B.3030205@freebsd.org> Date: Wed, 29 Jul 2015 17:26:11 +0800 Message-ID: Subject: Re: keep-state and in-kernel NAT exposes local ip on external interface From: bycn82 To: Julian Elischer Cc: freebsd-ipfw Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 09:26:14 -0000 *Hi Julian,* *So below are the rules in your example* *5 skipto 10 from A to B* *6 skipto 11 from any to any* *10{action} from A to B keep-state* *11{action} from C to D* *If I remove the "skipto" rules they will become* *10 {action} from A to B keep-state* *11 {action} from C to D * *Correct me if I was wrong, but in my opinion, the rule 5 and 10 are almost the same, so I dont see the benefit by introducing the "skipto" rulees. **IMHO, the "check-state" is to speed-up some selected packets, it will slow-down all other unexpected packets at the same time.* *Regards,* *bycn82* On 29 July 2015 at 15:39, Julian Elischer wrote: > On 7/29/15 3:43 AM, Lev Serebryakov wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 28.07.2015 08:30, Ian Smith wrote: >> >> I have global lack of any spare time (and all my FreeBSD activity is >> only a hobby) for last ~2 months. I see the end of this unfortunate >> state of affairs in near future and I remember about these examples. >> >> >>> there are some simple examples of things this patch addresses.. > For example in the current code, the following (extemely simplified) set of > rules will not do what you would think when you are working with a tcp > session from A to B and another from C to D *which has previously been** > **accepted with a keep-state at some other point in the ruleset* > > > 10 {any action} from A to B keep-state > 20 {any action} tcp from C to D > > because despite the fact that you are only triggering on a 'setup' packet > for A to B, any rule > that includes "keep-state" does a "check-state" implicitly. > so the packet from C to D never gets past rule 10. > the only way you can do this is to prefix rule 10 by something like > > 5 skipto 10 from A to B > 6 skipto 11 from any to any > > to make sure packets that are not A to B do not hit the hidden > 'check-state' . > > this is a very simple example and yes there are ways to get around it, > but it complicates the ruleset and increases errors > > that reminds me I'd also like to be able to put a "not" at the > front of the rule matching to negate the whole test but it doesn't seem to > like that. > > > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@freebsd.org Wed Jul 29 14:03:54 2015 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 12D749AD6BB for ; Wed, 29 Jul 2015 14:03:54 +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 E66C2E8C for ; Wed, 29 Jul 2015 14:03:53 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-239-102.lns20.per1.internode.on.net [121.45.239.102]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t6TE3l5m060582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 29 Jul 2015 07:03:51 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: keep-state and in-kernel NAT exposes local ip on external interface To: bycn82 References: <1435692039.18121.12.camel@yahoo.com> <5594395D.6050103@FreeBSD.org> <20150728150845.V17327@sola.nimnet.asn.au> <55B7DB52.7010504@FreeBSD.org> <55B8833B.3030205@freebsd.org> Cc: freebsd-ipfw From: Julian Elischer Message-ID: <55B8DD3D.1030900@freebsd.org> Date: Wed, 29 Jul 2015 22:03:41 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 14:03:54 -0000 On 7/29/15 5:26 PM, bycn82 wrote: > /Hi Julian,/ > / > / > /So below are the rules in your example/ > / > / > /5 skipto 10 from A to B > / > /6 skipto 11 from any to any/ > /10{action} from A to B keep-state/ > /11{action} from C to D/ > / > / > / > / > /If I remove the "skipto" rules they will become/ > // > /10 {action} from A to B keep-state/ > /11 {action} from C to D / > / > / > /Correct me if I was wrong, but in my opinion, the rule 5 and 10 > are almost the same, so I dont see the benefit by introducing the > "skipto" rulees. //IMHO, the "check-state" is to speed-up some > selected packets, it will slow-down all other unexpected packets at > the same time./ > / > / /so because C -D is already in the dynamic table it triggers on 10 and never reaches 11. see? you fell for it too. / > > /Regards,/ > /bycn82/ > > > > > On 29 July 2015 at 15:39, Julian Elischer > wrote: > > On 7/29/15 3:43 AM, Lev Serebryakov wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 28.07.2015 08:30, Ian Smith wrote: > > I have global lack of any spare time (and all my FreeBSD > activity is > only a hobby) for last ~2 months. I see the end of this > unfortunate > state of affairs in near future and I remember about these > examples. > > > there are some simple examples of things this patch addresses.. > For example in the current code, the following (extemely > simplified) set of > rules will not do what you would think when you are working with > a tcp > session from A to B and another from C to D *which has > previously been** > **accepted with a keep-state at some other point in the ruleset* > > > 10 {any action} from A to B keep-state > 20 {any action} tcp from C to D > > because despite the fact that you are only triggering on a > 'setup' packet for A to B, any rule > that includes "keep-state" does a "check-state" implicitly. > so the packet from C to D never gets past rule 10. > the only way you can do this is to prefix rule 10 by something like > > 5 skipto 10 from A to B > 6 skipto 11 from any to any > > to make sure packets that are not A to B do not hit the hidden > 'check-state' . > > this is a very simple example and yes there are ways to get > around it, > but it complicates the ruleset and increases errors > > that reminds me I'd also like to be able to put a "not" at the > front of the rule matching to negate the whole test but it > doesn't seem to like that. > > > > > _______________________________________________ > freebsd-ipfw@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to > "freebsd-ipfw-unsubscribe@freebsd.org > " > > From owner-freebsd-ipfw@freebsd.org Wed Jul 29 14:23:46 2015 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 E9E8F9ADE7E for ; Wed, 29 Jul 2015 14:23:46 +0000 (UTC) (envelope-from bycn82@gmail.com) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A399D1EEC; Wed, 29 Jul 2015 14:23:46 +0000 (UTC) (envelope-from bycn82@gmail.com) Received: by vnaa140 with SMTP id a140so2775696vna.2; Wed, 29 Jul 2015 07:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mOMRrHccQUY0rx/uwKKeqCER7cpSLR9tN+/SsEeSw4w=; b=NntNP5F0tuDBYt7RJaHlAkzHMgCWO2yjO9WSRt99W97/w1/WN28luspmXTrqiZTONI V5fHBu/IzPR8FJz2+tD8NuNTaP9fBhx8jM8GuWiBcoyKiOH+gWn3wFzLNj/Dr0t2cxAW ZyyRZOFr1NVDE0eqEoM44eyAlw12H04mx2YngY/tn41umwMB77mkpfqcs066XJ9Ju9qN 7kctb6e+Uy0fC41anKILKEsu/86MZl+LpGNchGlEvRvuhJpB8/aIN8LcOG3ppkZjLOr7 nmvotoHNBQh236RlTKWQ0IhNhz9pIYGi55VCq6InJimGJYSY/RwVGV1HPYehO+oW0ooB oNCA== MIME-Version: 1.0 X-Received: by 10.52.72.84 with SMTP id b20mr53025182vdv.6.1438179825612; Wed, 29 Jul 2015 07:23:45 -0700 (PDT) Received: by 10.31.174.6 with HTTP; Wed, 29 Jul 2015 07:23:45 -0700 (PDT) In-Reply-To: <55B8DD3D.1030900@freebsd.org> References: <1435692039.18121.12.camel@yahoo.com> <5594395D.6050103@FreeBSD.org> <20150728150845.V17327@sola.nimnet.asn.au> <55B7DB52.7010504@FreeBSD.org> <55B8833B.3030205@freebsd.org> <55B8DD3D.1030900@freebsd.org> Date: Wed, 29 Jul 2015 22:23:45 +0800 Message-ID: Subject: Re: keep-state and in-kernel NAT exposes local ip on external interface From: bycn82 To: Julian Elischer Cc: freebsd-ipfw Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 14:23:47 -0000 *Hi,* *But I dont understand why you said C->D is already in the dynamic table? which line create the dynamic rule for it?* *Regards,* *bycn82* On 29 July 2015 at 22:03, Julian Elischer wrote: > On 7/29/15 5:26 PM, bycn82 wrote: > > *Hi Julian,* > > *So below are the rules in your example* > > > *5 skipto 10 from A to B * > *6 skipto 11 from any to any* > *10{action} from A to B keep-state* > *11{action} from C to D* > > > *If I remove the "skipto" rules they will become* > > *10 {action} from A to B keep-state* > *11 {action} from C to D * > > *Correct me if I was wrong, but in my opinion, the rule 5 and 10 are > almost the same, so I dont see the benefit by introducing the "skipto" > rulees. **IMHO, the "check-state" is to speed-up some selected packets, > it will slow-down all other unexpected packets at the same time.* > > > > > *so because C -D is already in the dynamic table it triggers on 10 and > never reaches 11. see? you fell for it too. * > > > *Regards,* > *bycn82* > > > > > On 29 July 2015 at 15:39, Julian Elischer wrote: > >> On 7/29/15 3:43 AM, Lev Serebryakov wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>> >>> On 28.07.2015 08:30, Ian Smith wrote: >>> >>> I have global lack of any spare time (and all my FreeBSD activity is >>> only a hobby) for last ~2 months. I see the end of this unfortunate >>> state of affairs in near future and I remember about these examples. >>> >>> >>>> there are some simple examples of things this patch addresses.. >> For example in the current code, the following (extemely simplified) set >> of >> rules will not do what you would think when you are working with a tcp >> session from A to B and another from C to D *which has previously been** >> **accepted with a keep-state at some other point in the ruleset* >> >> >> 10 {any action} from A to B keep-state >> 20 {any action} tcp from C to D >> >> because despite the fact that you are only triggering on a 'setup' packet >> for A to B, any rule >> that includes "keep-state" does a "check-state" implicitly. >> so the packet from C to D never gets past rule 10. >> the only way you can do this is to prefix rule 10 by something like >> >> 5 skipto 10 from A to B >> 6 skipto 11 from any to any >> >> to make sure packets that are not A to B do not hit the hidden >> 'check-state' . >> >> this is a very simple example and yes there are ways to get around it, >> but it complicates the ruleset and increases errors >> >> that reminds me I'd also like to be able to put a "not" at the >> front of the rule matching to negate the whole test but it doesn't seem >> to like that. >> >> >> >> >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >> > > > From owner-freebsd-ipfw@freebsd.org Wed Jul 29 19:34:49 2015 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 650C09AD038 for ; Wed, 29 Jul 2015 19:34:49 +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 43E546DC for ; Wed, 29 Jul 2015 19:34:48 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-239-102.lns20.per1.internode.on.net [121.45.239.102]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t6TJYgJ5061671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 29 Jul 2015 12:34:46 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: keep-state and in-kernel NAT exposes local ip on external interface To: bycn82 References: <1435692039.18121.12.camel@yahoo.com> <5594395D.6050103@FreeBSD.org> <20150728150845.V17327@sola.nimnet.asn.au> <55B7DB52.7010504@FreeBSD.org> <55B8833B.3030205@freebsd.org> <55B8DD3D.1030900@freebsd.org> Cc: freebsd-ipfw From: Julian Elischer Message-ID: <55B92ACC.6090505@freebsd.org> Date: Thu, 30 Jul 2015 03:34:36 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 19:34:49 -0000 On 7/29/15 10:23 PM, bycn82 wrote: > /Hi,/ > /But I dont understand why you said C->D is already in the dynamic > table? which line create the dynamic rule for it?/ /it happened on a previous packet at some other rule, for example 30 allow ip from any to D 80 keep-state / > / > / > /Regards,/ > /bycn82/ > > On 29 July 2015 at 22:03, Julian Elischer > wrote: > > On 7/29/15 5:26 PM, bycn82 wrote: >> /Hi Julian,/ >> / >> / >> /So below are the rules in your example/ >> / >> / >> /5 skipto 10 from A to B >> / >> /6 skipto 11 from any to any/ >> /10{action} from A to B keep-state/ >> /11{action} from C to D/ >> / >> / >> / >> / >> /If I remove the "skipto" rules they will become/ >> // >> /10 {action} from A to B keep-state/ >> /11 {action} from C to D / >> / >> / >> /Correct me if I was wrong, but in my opinion, the rule 5 and >> 10 are almost the same, so I dont see the benefit by >> introducing the "skipto" rulees. //IMHO, the "check-state" is >> to speed-up some selected packets, it will slow-down all other >> unexpected packets at the same time./ >> / >> / > /so because C -D is already in the dynamic table it triggers on > 10 and never reaches 11. > see? you fell for it too. > > / >> >> /Regards,/ >> /bycn82/ >> >> >> >> >> On 29 July 2015 at 15:39, Julian Elischer > > wrote: >> >> On 7/29/15 3:43 AM, Lev Serebryakov wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 28.07.2015 08:30, Ian Smith wrote: >> >> I have global lack of any spare time (and all my >> FreeBSD activity is >> only a hobby) for last ~2 months. I see the end of this >> unfortunate >> state of affairs in near future and I remember about >> these examples. >> >> >> there are some simple examples of things this patch addresses.. >> For example in the current code, the following (extemely >> simplified) set of >> rules will not do what you would think when you are working >> with a tcp >> session from A to B and another from C to D *which has >> previously been** >> **accepted with a keep-state at some other point in the >> ruleset* >> >> >> 10 {any action} from A to B keep-state >> 20 {any action} tcp from C to D >> >> because despite the fact that you are only triggering on a >> 'setup' packet for A to B, any rule >> that includes "keep-state" does a "check-state" implicitly. >> so the packet from C to D never gets past rule 10. >> the only way you can do this is to prefix rule 10 by >> something like >> >> 5 skipto 10 from A to B >> 6 skipto 11 from any to any >> >> to make sure packets that are not A to B do not hit the >> hidden 'check-state' . >> >> this is a very simple example and yes there are ways to >> get around it, >> but it complicates the ruleset and increases errors >> >> that reminds me I'd also like to be able to put a "not" at the >> front of the rule matching to negate the whole test but it >> doesn't seem to like that. >> >> >> >> >> _______________________________________________ >> freebsd-ipfw@freebsd.org >> mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to >> "freebsd-ipfw-unsubscribe@freebsd.org >> " >> >> > > From owner-freebsd-ipfw@freebsd.org Wed Jul 29 19:47:19 2015 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 D44F09AD40C for ; Wed, 29 Jul 2015 19:47:19 +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 B5629BD6 for ; Wed, 29 Jul 2015 19:47:19 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-239-102.lns20.per1.internode.on.net [121.45.239.102]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t6TJlEbE061713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 29 Jul 2015 12:47:17 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: keep-state and in-kernel NAT exposes local ip on external interface To: bycn82 References: <1435692039.18121.12.camel@yahoo.com> <5594395D.6050103@FreeBSD.org> <20150728150845.V17327@sola.nimnet.asn.au> <55B7DB52.7010504@FreeBSD.org> <55B8833B.3030205@freebsd.org> <55B8DD3D.1030900@freebsd.org> <55B92ACC.6090505@freebsd.org> Cc: freebsd-ipfw From: Julian Elischer Message-ID: <55B92DBB.5050204@freebsd.org> Date: Thu, 30 Jul 2015 03:47:07 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B92ACC.6090505@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 19:47:19 -0000 On 7/30/15 3:34 AM, Julian Elischer wrote: > On 7/29/15 10:23 PM, bycn82 wrote: >> /Hi,/ >> /But I dont understand why you said C->D is already in the dynamic >> table? which line create the dynamic rule for it?/ > > /it happened on a previous packet at some other rule, for example > 30 allow ip from any to D 80 keep-state reread the original example description.. > > > / >> / >> / >> /Regards,/ >> /bycn82/ >> >> On 29 July 2015 at 22:03, Julian Elischer > > wrote: >> >> On 7/29/15 5:26 PM, bycn82 wrote: >>> /Hi Julian,/ >>> / >>> / >>> /So below are the rules in your example/ >>> / >>> / >>> /5 skipto 10 from A to B >>> / >>> /6 skipto 11 from any to any/ >>> /10{action} from A to B keep-state/ >>> /11{action} from C to D/ >>> / >>> / >>> / >>> / >>> /If I remove the "skipto" rules they will become/ >>> // >>> /10 {action} from A to B keep-state/ >>> /11 {action} from C to D / >>> / >>> / >>> /Correct me if I was wrong, but in my opinion, the rule 5 and >>> 10 are almost the same, so I dont see the benefit by >>> introducing the "skipto" rulees. //IMHO, the "check-state" is >>> to speed-up some selected packets, it will slow-down all other >>> unexpected packets at the same time./ >>> / >>> / >> /so because C -D is already in the dynamic table it triggers on >> 10 and never reaches 11. >> see? you fell for it too. >> >> / >>> >>> /Regards,/ >>> /bycn82/ >>> >>> >>> >>> >>> On 29 July 2015 at 15:39, Julian Elischer >> > wrote: >>> >>> On 7/29/15 3:43 AM, Lev Serebryakov wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>> >>> On 28.07.2015 08:30, Ian Smith wrote: >>> >>> I have global lack of any spare time (and all my >>> FreeBSD activity is >>> only a hobby) for last ~2 months. I see the end of this >>> unfortunate >>> state of affairs in near future and I remember about >>> these examples. >>> >>> >>> there are some simple examples of things this patch >>> addresses.. >>> For example in the current code, the following (extemely >>> simplified) set of >>> rules will not do what you would think when you are working >>> with a tcp >>> session from A to B and another from C to D *which has >>> previously been accepted with a keep-state at some other >>> point in the >>> ruleset* >>> >>> >>> 10 {any action} from A to B keep-state >>> 20 {any action} tcp from C to D >>> >>> because despite the fact that you are only triggering on a >>> 'setup' packet for A to B, any rule >>> that includes "keep-state" does a "check-state" implicitly. >>> so the packet from C to D never gets past rule 10. >>> the only way you can do this is to prefix rule 10 by >>> something like >>> >>> 5 skipto 10 from A to B >>> 6 skipto 11 from any to any >>> >>> to make sure packets that are not A to B do not hit the >>> hidden 'check-state' . >>> >>> this is a very simple example and yes there are ways to >>> get around it, >>> but it complicates the ruleset and increases errors >>> >>> that reminds me I'd also like to be able to put a "not" at >>> the >>> front of the rule matching to negate the whole test but it >>> doesn't seem to like that. >>> >>> >>> >>> >>> _______________________________________________ >>> freebsd-ipfw@freebsd.org >>> mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >>> To unsubscribe, send any mail to >>> "freebsd-ipfw-unsubscribe@freebsd.org >>> " >>> >>> >> >> > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@freebsd.org Thu Jul 30 18:25:53 2015 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 0CAC99AB185 for ; Thu, 30 Jul 2015 18:25:53 +0000 (UTC) (envelope-from hiren@FreeBSD.org) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (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 E00D711E2 for ; Thu, 30 Jul 2015 18:25:52 +0000 (UTC) (envelope-from hiren@FreeBSD.org) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id D544FD0522; Thu, 30 Jul 2015 11:25:51 -0700 (PDT) Date: Thu, 30 Jul 2015 11:25:51 -0700 From: hiren panchasara To: Ian Smith Cc: freebsd-ipfw@freebsd.org Subject: Re: Traffic not going through dummynet Message-ID: <20150730182551.GF39365@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eVzOFob/8UvintSX" Content-Disposition: inline In-Reply-To: <20150726181056.C17327@sola.nimnet.asn.au> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 18:25:53 -0000 --eVzOFob/8UvintSX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (For various reason's I didn't get/see Ian's message. Trying to do the right thing by setting "In-Reply-To".) On 07/27/15 at 01:07P, Ian Smith wrote: > On Sun, 19 Jul 2015 21:05:53 -0700, hiren panchasara wrote: > > Bah. > >=20 > > So I removed ipfw and dummynet from kernconf and loaded them manually > > after machine came up and it worked as expected. >=20 > In your previous post, you'd said you were using 11-current, and: >=20 > > And GENERIC has: > > options IPFIREWALL > > options DUMMYNET > > options HZ=3D1000 >=20 > Are you sure this was a 11 GENERIC kernconf? Those options haven't=20 > been in GENERIC for ages (if ever?), though they haven't needed to be=20 > since (perhaps) 8.0. I guess people just follow the handbook :( I modified GENERIC and added those options. I should have been more clear here. >=20 > > Looks like some ordering issue between ipfw and dummynet. Fwiw, for > > working setup, kldstat shows: > >=20 > > 13 2 0xffffffff81e21000 21490 ipfw.ko > > 14 1 0xffffffff81e43000 d0f6 dummynet.ko >=20 > Indeed. If you load ipfw and dummynet by the usual means, being=20 > firewall_enable=3DYES and dummynet_enable=3DYES in rc.conf, you'll notice= =20 > that /etc/rc.d/ipfw, in ipfw_prestart, loads dummynet if enabled, and=20 > natd and/or firewall_nat if enabled, in that order. >=20 > The downside to doing that is that you have to have specified a type for= =20 > rc.firewall or pointed to a custom ruleset so it's sane on startup. Didn't know the usual mean of rc.conf modifications. >=20 > Regarding the related(?) Bug 201488 - dummynet appears broken in=20 > 10.0-RELEASE and onwards (can't traffic shape on bridges) > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D201488 > it does seem likely to be the same issue as you noted. >=20 > Did you ever hear back from James Rice (for whom I seem to have seen no= =20 > other messages for an email address) as to whether your advice about=20 > loading these in the other order helped there? I haven't heard back yet. >=20 > As to whether this is a regression, or it would have ever worked loading= =20 > dummynet and then ipfw, I don't know, but I have a vague feeling that=20 > I've seen other issues regarding loading a module that's already in=20 > kernel in recent times .. sorry I can't be any more exact. Yeah, good point about whether this is a regression or not. I am not aware of any such loading issues wrt modules. >=20 > Maybe dummynet needs a check that ipfw is loaded before starting? That'd be logical, imo. Cheers, Hiren --eVzOFob/8UvintSX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVumwuXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lIKMH/AhnqfbqlQm3viX/wQC7p4iS mZbmxU8OFLm/AXDT0P7tnaw/hsvPeJ0Dcxum45FxE8+/R7Zj0u0qTVytoHdO9/6Y WiL7WxJi9lxVQoThx5yvRm0sLBHnFpJz8P8tkNIEwjyxzRSw9LuJdtLmnaVlCtrd ZV80nq99lgqYix/E86D/61McugjRfycxJBr4XEdxngLpAHa0RRYDjEOMH2LdvZzh ysru6q6yYGUeLMeFjxFKsbrffFRf5RpEBKKZYtmKSGWhjGvsUO1EvSeXBgJNsLuP 0EoY3Z5Id1vNDNZJ0/tlsbv8sUliwSuxYint2/374JeRPhVCUI0kRV+f7Dyu4+8= =dvEU -----END PGP SIGNATURE----- --eVzOFob/8UvintSX-- From owner-freebsd-ipfw@freebsd.org Fri Jul 31 10:23:12 2015 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 4A4519AF81A for ; Fri, 31 Jul 2015 10:23:12 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 59EE81DC8; Fri, 31 Jul 2015 10:23:10 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t6VAN7bO065578; Fri, 31 Jul 2015 20:23:07 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 31 Jul 2015 20:23:07 +1000 (EST) From: Ian Smith To: hiren panchasara cc: freebsd-ipfw@FreeBSD.org Subject: Re: Traffic not going through dummynet In-Reply-To: <20150730182551.GF39365@strugglingcoder.info> Message-ID: <20150731171616.J17327@sola.nimnet.asn.au> References: <20150730182551.GF39365@strugglingcoder.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 10:23:12 -0000 On Thu, 30 Jul 2015 11:25:51 -0700, hiren panchasara wrote: > (For various reason's I didn't get/see Ian's message. Trying to do the > right thing by setting "In-Reply-To".) No problem, thanks. > On 07/27/15 at 01:07P, Ian Smith wrote: > > On Sun, 19 Jul 2015 21:05:53 -0700, hiren panchasara wrote: > > > Bah. > > > > > > So I removed ipfw and dummynet from kernconf and loaded them manually > > > after machine came up and it worked as expected. > > > > In your previous post, you'd said you were using 11-current, and: > > > > > And GENERIC has: > > > options IPFIREWALL > > > options DUMMYNET > > > options HZ=1000 > > > > Are you sure this was a 11 GENERIC kernconf? Those options haven't > > been in GENERIC for ages (if ever?), though they haven't needed to be > > since (perhaps) 8.0. I guess people just follow the handbook :( > > I modified GENERIC and added those options. I should have been more > clear here. Yeah, the handbook tends to lead one that way. I 'include GENERIC' and use no{options,device} as needed; saves me getting even more confused :) > > > Looks like some ordering issue between ipfw and dummynet. Fwiw, for > > > working setup, kldstat shows: > > > > > > 13 2 0xffffffff81e21000 21490 ipfw.ko > > > 14 1 0xffffffff81e43000 d0f6 dummynet.ko > > > > Indeed. If you load ipfw and dummynet by the usual means, being > > firewall_enable=YES and dummynet_enable=YES in rc.conf, you'll notice > > that /etc/rc.d/ipfw, in ipfw_prestart, loads dummynet if enabled, and > > natd and/or firewall_nat if enabled, in that order. > > > > The downside to doing that is that you have to have specified a type for > > rc.firewall or pointed to a custom ruleset so it's sane on startup. > > Didn't know the usual mean of rc.conf modifications. Checking /etc/defaults/rc.conf /firewall_, all you'd need for that is: firewall_enable=YES firewall_type=OPEN # permit all, regardless of default_to_accept dummynet_anable=YES which would at least load those modules in the right order, however as shown below, you didn't need to be so fussy, up to 9.3 anyway. > > Regarding the related(?) Bug 201488 - dummynet appears broken in > > 10.0-RELEASE and onwards (can't traffic shape on bridges) > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201488 > > it does seem likely to be the same issue as you noted. > > > > Did you ever hear back from James Rice (for whom I seem to have seen no > > other messages for an email address) as to whether your advice about > > loading these in the other order helped there? > > I haven't heard back yet. > > > > As to whether this is a regression, or it would have ever worked loading > > dummynet and then ipfw, I don't know, but I have a vague feeling that > > I've seen other issues regarding loading a module that's already in > > kernel in recent times .. sorry I can't be any more exact. Actually the other one was someone loading urtwn with it already in kernel getting bad results; I suggested trying without it in kernel, but haven't heard back either. > Yeah, good point about whether this is a regression or not. I am not > aware of any such loading issues wrt modules. In the olden days, attempting to load a module already in kernel would fail gracefully with a message early on in dmesg. I'm still wondering if there's some issue there. I'll try loading dummynet before ipfw on my 9.3 system using a similar setup to yours such as noticeable delay. > > Maybe dummynet needs a check that ipfw is loaded before starting? > > That'd be logical, imo. Will I ever learn to not suggest things I can't actually fix myself? :) Ok, here's a near-duplicate on 9.3-R of your procedure on 11.0 root@x200:~ # kldstat -v | egrep 'ipfw|dummynet' root@x200:~ # kldload dummynet root@x200:~ # kldstat -v | egrep 'ipfw|dummynet' 9 1 0xffffffff81a3b000 d910 dummynet.ko (/boot/kernel/dummynet.ko) 511 dummynet 10 1 0xffffffff81a49000 12200 ipfw.ko (/boot/kernel/ipfw.ko) 510 ipfw [ note that loading dummynet also loads ipfw - as expected I guess - and that they're here listed in that reverse order numerically, FWIW ] root@x200:~ # ipfw -t show 65535 0 0 deny ip from any to any root@x200:~ # ipfw add 65000 allow ip from any to any 65000 allow ip from any to any root@x200:~ # ipfw -t show 65000 0 0 allow ip from any to any 65535 2 560 Fri Jul 31 19:28:47 2015 deny ip from any to any [ I didn't reboot, so added the allow-all rule. I'd normally use the method of running 'kldload ipfw && ipfw add 32000 ip from any to any' from a remote ssh session, but 'kldload dummynet', since it auto-loads ipfw with default-deny rule, naturally killed my login ] root@x200:~ # ipfw add 32000 pipe 1 ip from any to any 32000 pipe 1 ip from any to any root@x200:~ # ipfw pipe 1 config delay 100ms root@x200:~ # ipfw -t show 32000 0 0 pipe 1 ip from any to any 65000 1 112 Fri Jul 31 19:28:59 2015 allow ip from any to any 65535 2 560 Fri Jul 31 19:28:47 2015 deny ip from any to any root@x200:~ # ipfw pipe show 00001: unlimited 100 ms burst 0 q131073 50 sl. 0 flows (1 buckets) sched 65537 weight 0 lmax 0 pri 0 droptail sched 65537 type FIFO flags 0x0 0 buckets 0 active root@x200:~ # sysctl kern.features | grep ipfw # not on 9.3 root@x200:~ # sysctl net.inet.ip.dummynet | grep io # if relevant net.inet.ip.dummynet.io_pkt_drop: 0 net.inet.ip.dummynet.io_pkt_fast: 0 net.inet.ip.dummynet.io_pkt: 7 net.inet.ip.dummynet.io_fast: 0 root@x200:~ # ping t23 PING t23 (192.168.7.7): 56 data bytes 64 bytes from 192.168.7.7: icmp_seq=0 ttl=64 time=198.792 ms 64 bytes from 192.168.7.7: icmp_seq=1 ttl=64 time=199.997 ms 64 bytes from 192.168.7.7: icmp_seq=2 ttl=64 time=199.884 ms ^C --- t23 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 198.792/199.558/199.997/0.543 ms root@x200:~ # ipfw disable one_pass # no diff in this context root@x200:~ # ping t23 PING t23 (192.168.7.7): 56 data bytes 64 bytes from 192.168.7.7: icmp_seq=0 ttl=64 time=198.273 ms 64 bytes from 192.168.7.7: icmp_seq=1 ttl=64 time=200.964 ms 64 bytes from 192.168.7.7: icmp_seq=2 ttl=64 time=200.041 ms ^C --- t23 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 198.273/199.759/200.964/1.117 ms root@x200:~ # ipfw pipe show 00001: unlimited 100 ms burst 0 q131073 50 sl. 0 flows (1 buckets) sched 65537 weight 0 lmax 0 pri 0 droptail sched 65537 type FIFO flags 0x0 0 buckets 0 active root@x200:~ # ipfw -t show 32000 25 4060 Fri Jul 31 19:37:59 2015 pipe 1 ip from any to any 65000 8 728 Fri Jul 31 19:37:59 2015 allow ip from any to any 65535 2 560 Fri Jul 31 19:28:47 2015 deny ip from any to any root@x200:~ # ipfw add 2000 skipto 40000 ip from any to any 02000 skipto 40000 ip from any to any root@x200:~ # ping t23 PING t23 (192.168.7.7): 56 data bytes 64 bytes from 192.168.7.7: icmp_seq=0 ttl=64 time=0.447 ms 64 bytes from 192.168.7.7: icmp_seq=1 ttl=64 time=0.392 ms 64 bytes from 192.168.7.7: icmp_seq=2 ttl=64 time=0.549 ms 64 bytes from 192.168.7.7: icmp_seq=3 ttl=64 time=0.607 ms ^C --- t23 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.392/0.499/0.607/0.084 ms [ note here I'd bypassed the pipe rule, and unloading dummynet is ok, ie it doesn't just then unload ipfw too ] root@x200:~ # kldunload dummynet root@x200:~ # ping t23 PING t23 (192.168.7.7): 56 data bytes 64 bytes from 192.168.7.7: icmp_seq=0 ttl=64 time=0.512 ms 64 bytes from 192.168.7.7: icmp_seq=1 ttl=64 time=0.392 ms ^C --- t23 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.392/0.452/0.512/0.060 ms [ but as soon as I delete that bypass rule, it's all over .. ] root@x200:~ # ipfw delete 2000 ipfw: rule 2000: setsockopt(IP_FW_DEL): Protocol not available root@x200:~ # ipfw -t show ipfw: getsockopt(IP_FW_GET): Protocol not available root@x200:~ # kldstat -v | egrep 'ipfw|dummynet' root@x200:~ # ======= So in summary: the behaviour you demonstrated on 11.0 does not occur on 9.3 - assuming I did things in the same order that you did - so it does indeed seem to be a regression. I have no 10.x system to test. cheers, Ian From owner-freebsd-ipfw@freebsd.org Fri Jul 31 16:43:28 2015 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 6356B9AFBDB for ; Fri, 31 Jul 2015 16:43:28 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28D431CDC for ; Fri, 31 Jul 2015 16:43:27 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by qkfc129 with SMTP id c129so31105233qkf.1 for ; Fri, 31 Jul 2015 09:43:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=r8reNJTHJHPPxv7j2F1B0TjF5J0c+TX7vzv2+Dnittg=; b=ZGVtErO4FzBzkYdsP36l4oLVN43J7hzw0ScnjN/cuMlNe3IzAlukJKrjy6kqXJXrZg vhlLiajCyvnJ1Rw9Xlce5Sj/coX/Fi29p8zviXRSKSdWaeya83BQUzJWOPLX1n56tGql D1DZzcZ3bs15yRXm4Cgbtn/+/hCVzO9cLK1usOOuQw0TBsMjl1/XWDaagwTTLhbracZS oHzAH8EIOTQRpcq5DpGJbsNRjD4gUOtXFgR5y5mdA3AkxDwV9dtL6At+1h0cy82LJ11a jnwQmcRr7Mu+lI9yzagNozAY+h8sC6/Deh4yhZSvTHmK26Af93g2EFTaYqfAHLClGjLq lLvQ== X-Gm-Message-State: ALoCoQn1frHlm6T3DXsC2FGVJZwx5rfr1fcPJF6lBx+uo0Z9CukKSb+ZwPs8M4g88kgkZAxWd/np MIME-Version: 1.0 X-Received: by 10.55.26.167 with SMTP id l39mr5674951qkh.14.1438361006582; Fri, 31 Jul 2015 09:43:26 -0700 (PDT) Received: by 10.140.41.197 with HTTP; Fri, 31 Jul 2015 09:43:25 -0700 (PDT) Received: by 10.140.41.197 with HTTP; Fri, 31 Jul 2015 09:43:25 -0700 (PDT) In-Reply-To: <20150731171616.J17327@sola.nimnet.asn.au> References: <20150730182551.GF39365@strugglingcoder.info> <20150731171616.J17327@sola.nimnet.asn.au> Date: Fri, 31 Jul 2015 09:43:25 -0700 Message-ID: Subject: Re: Traffic not going through dummynet From: Michael Sierchio To: Ian Smith Cc: freebsd-ipfw@freebsd.org, hiren panchasara Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 16:43:28 -0000 On Jul 31, 2015 3:23 AM, "Ian Smith" wrote: > > firewall_enable=YES > firewall_type=OPEN # permit all, regardless of default_to_accept > dummynet_anable=YES > > which would at least load those modules in the right order, The order of variables in /etc/rc.conf is irrelevant, except that a later assignment for the same variable will overwrite the value. - M From owner-freebsd-ipfw@freebsd.org Fri Jul 31 17:18:35 2015 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 715139B01FA for ; Fri, 31 Jul 2015 17:18:35 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E40561FFF; Fri, 31 Jul 2015 17:18:34 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t6VHIb4W079801; Sat, 1 Aug 2015 03:18:37 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 1 Aug 2015 03:18:37 +1000 (EST) From: Ian Smith To: Michael Sierchio cc: freebsd-ipfw@freebsd.org, hiren panchasara Subject: Re: Traffic not going through dummynet In-Reply-To: Message-ID: <20150801030720.J17327@sola.nimnet.asn.au> References: <20150730182551.GF39365@strugglingcoder.info> <20150731171616.J17327@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:18:35 -0000 On Fri, 31 Jul 2015 09:43:25 -0700, Michael Sierchio wrote: > On Jul 31, 2015 3:23 AM, "Ian Smith" wrote: > > > > > firewall_enable=YES > > firewall_type=OPEN # permit all, regardless of default_to_accept > > dummynet_anable=YES > > > > which would at least load those modules in the right order, > > The order of variables in /etc/rc.conf is irrelevant, except that a later > assignment for the same variable will overwrite the value. Yes, quite so. Sorry, I was referring to earlier in the thread about using the rc mechanism via rc.conf with /etc/rc.d/ipfw, which then loads dummynet at the right time; rather than invoking dummynet by preloading, which seems to be triggering this regression from sometime? after 9.x cheers, Ian