Question that has dogged me for a while.

[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'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.

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

....
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?

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2993 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20170505/3b322706/attachment.bin>