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-----