On 6/5/17 7:53 am, Karl Denninger wrote:
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'm loathe to stick "illegal" (e.g. bad IP number)
packets on a network in any event, so while yeah, that'll work I'd
rather not.
Interestingly the "bad" IP packets are no different than the packets
you are seeing on the network anyhow (with nat).
You just deliver them to a different place.
Effectively you are turning on the transparent proxy support in the
kernel and making the gateway a transparent proxy for your clients.
(but only for your own server)
for example if your client is 192.168.0.2
and your server is 192.168.0.3 and your external address is 8.8.8.9,
Then what you are asking for is a way that your client can make a
session where the remote address is 8.8.8.9 and the local address is
192.168.0.2.
You are going to generate these packets no matter what you do because
they are what you asked to do even if you are NATing.
The packets when bounced to the server STILL look like
src=192.169.0.2, dest=8.8.8.9 and the server(FreeBSD or Linux with TP
support only) will consume them as such.
The server will produce a packet that looks like src=8.8.8.9,
dest=192.168.0.2. These packets look exactly like the packets that
would be returning from the NAT to the client had you used nat.
so, overall, you are not introducing any packets onto your network
that wouldn't have been there anyhow.
They look exactly like the traffic would look between the NAT and the
client.
The difference is that it is way more efficient, because the return
packets take no processing at all.
The advantage of setting up a DNS (mostly) forwarding proxy is that
what is happening is absolutely visible on the wire.
Nothing is pretending to be anything it is not.
The nat option on the other hand.
(don't get me wrong, I am sure it would work given enough work) is
that it just has more moving parts and will make it more complicated
to get your firewall correct in other cases.
I like ipfw and it's nat, it's just more complicated in some cases.
The "set up a fake forward" zone thing works too, but it shouldn't have to.
This /should /work on a generalized basis but doesn't (ue1 is on the
public address 70.169.168.7, ue0 on private address 192.168.10.200, the
host being "twisted to/hole punched" is on 192.168.10.100:
# Set up the NAT configuration
#
${fwcmd} nat 100 config if ue1 log same_ports reset
redirect_port tcp 192.168.10.100:2552 2552
${fwcmd} nat 200 config ip 192.168.10.200 log same_ports reset
shouldn't one of these be declared to be a reverse nat?
....
06000 0 0 nat 200 ip4 from 192.168.0.0/16 2552 to 192.168.10.200
06010 1521 726601 nat 100 ip4 from any to me recv ue1
07000 0 0 check-state :default
08000 6 312 nat 200 ip4 from 192.168.0.0/16 to 70.169.168.7
08001 0 0 count log ip4 from 192.168.10.200 to any dst-port 2552
08002 2125 2408339 nat 100 ip4 from 192.168.0.0/16 to any xmit ue1
08009 0 0 deny log ip4 from 192.168.0.0/16 to any xmit ue1
A "telnet 70.169.168.7 2552" from outside works perfectly well. But the
second NAT should cause a "telnet 70.169.168.7 2552" from an
internet-network host to work also. It doesn't.
8000 gets the packet (a telnet attempt from inside to port 2552) and
allegedly is supposed to NAT it. It does not. The following rule,
which is where execution should continue after it NATs it, should match
but no packet ever comes back into the stack -- nor does it show up on
the wire (tcpdump fails to show it.) I have verbose logging on in
sysctl and none of the deny lines in the remainder of the ipfw config
file trap it either.
The *other* NAT instance on the same box (to translate other things on
the same network out to the Internet at large and perform the hole
punch) works perfectly well.
This looks like a bug in the code -- unless there's a requirement that a
packet in the kernel is marked to be enqueued for emission on an actual
physical interface before it will translate (e.g. a "forward" NAT has to
be associated with an "xmit ...." clause in order to work) in which case
it's impossible to make in-kernel NAT work for the "double twist" case
since the packet never leaves the box until it goes through the
hole-punch in the first NAT statement (which it *should* do in 8002,
right?)
Is that a bug (ought to PR it), a "feature" (e.g. design choice and thus
"working as intended") or do I (still) have it configured incorrectly?
_______________________________________________
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"
