Date: Tue, 28 Jul 2015 22:43:14 +0300 From: Lev Serebryakov <lev@FreeBSD.org> To: Ian Smith <smithi@nimnet.asn.au> Cc: freebsd-ipfw@freebsd.org Subject: Re: keep-state and in-kernel NAT exposes local ip on external interface Message-ID: <55B7DB52.7010504@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55B7DB52.7010504>