Question that has dogged me for a while.

[Julian Elischer]

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 <karl at denninger.net>:
>>> 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.

>