From owner-freebsd-ipfw@freebsd.org Sat May 6 04:11:16 2017 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 09E4AD604C1 for ; Sat, 6 May 2017 04:11:16 +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 E43E2F9C for ; Sat, 6 May 2017 04:11:15 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (58-7-94-137.dyn.iinet.net.au [58.7.94.137]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v464B8QI098453 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 5 May 2017 21:11:12 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Question that has dogged me for a while. To: Karl Denninger , freebsd-ipfw@freebsd.org References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> <6f304edb-ad2e-cb2a-eea9-7b6bbe0be760@freebsd.org> <52f73440-c1f0-7f08-0f8e-f912436ee686@denninger.net> <11FA2DA2-85AB-4E70-B9B5-CDADAAA3C295@obsigna.com> <29c05b94-be21-2090-03c5-f3905d3e2e06@denninger.net> From: Julian Elischer Message-ID: <06caae0c-2342-71af-0456-342c68b82c2a@freebsd.org> Date: Sat, 6 May 2017 12:11:02 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <29c05b94-be21-2090-03c5-f3905d3e2e06@denninger.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 04:11:16 -0000 On 6/5/17 8:14 am, Karl Denninger wrote: > On 5/5/2017 19:08, Dr. Rolf Jansen wrote: >> Am 05.05.2017 um 20:53 schrieb Karl Denninger : >>> On 5/5/2017 14:33, Julian Elischer wrote: >>>> On 5/5/17 1:48 am, Dr. Rolf Jansen wrote: >>>>> Resolving this with ipfw/NAT may easily become quite complicated, if >>>>> not impossible if you want to run a stateful nat'ting firewall, which >>>>> is usually the better choice. >>>>> >>>>> IMHO a DNS based solution is much more effective. >>>>> >>>>> On my gateway I have running the caching DNS resolver Unbound. Now >>>>> let's assume, the second level domain name in question is >>>>> example.com, and your web server would be accessed by >>>>> www.example.com, while other services, e.g. mail are served from >>>>> other sites on the internet. >>>> I believe this is a much cleaner solution thanusing double NAT. >>>> (see also my solution for if the server is also freebsd) >>>> even though we have a nice set of new IPFW capabilities that can do >>>> this, I still think double nat is an over complication of the system. >>>> >>> Well, the DNS answer is one that works IF you control the zone in >>> question every time. ... >> I do not understand "control the zone ... every time". >> >> I set up my transparent zones 5 years ago and never touched it again, and I don't see any "illegal" packets on my network caused by this either. >> >> I understand that you actually didn't grasp the transparent zone technic. >> >> Happy double nat'ting :-D > On the contrary I do understand it (and how to do it), along with how to > throw "off-network" packets at the other host. Both ways work (unbound > is arguably simpler than BIND, but it'll work in both cases) but the > point is that you then must keep two things in sync rather than do one > thing in one place. > > If double-nat'ing isn't supposed to work with in-kernel ipfw nat because > the first nat never leaves an interface then it is what it is, but if it > IS supposed to work then is not this misfeature a roach on the floor > that perhaps ought to get squashed? I think the problem MAY be that the return packets from the internal (reverse) nat are taking the same path as the original packets. (confusing libalias) You are saying that the packets coming from 192.168.x.x are CLIENT packets and then you expect the packets from the server to be treated the differently, even tough they are the same. I think the NAT doesn't know which way to apply them as. >