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 <k...@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.
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
