Question that has dogged me for a while.

Karl Denninger karl at denninger.net
Thu May 4 18:06:22 UTC 2017


On 5/4/2017 12:12, Rodney W. Grimes wrote:
>> Consider the following network configuration.
>>
>>
>> Internet ------- Gateway/Firewall ---------- Inside network (including a
>> web host)
>>             70.16.10.1/28     192.168.0.0/24  
>>
>> The address of the outside is FICTIONAL, by the way.
>>
>> For policy reasons I do NOT want the gateway machine to actually have
>> the host on it.  There may be a number of things running on there but
>> for the instant moment let's assume a standard pedestrian web host on
>> port 80.
>>
>> I have DNS pointing at "webhost.domain" @ 70.16.10.1.
>>
>> I have NAT on the gateway (NAT internal to the kernel), and a "hole
>> punch" in there with redirect_port tcp 192.168.1.1:80 70.16.10.1:80 as
>> pat of the nat configuration statement.
>>
>> This works fine for anyone on the outside.  HOWEVER, anyone on the
>> INTERNAL network cannot see the host.
>>
>> My NAT configuration looks like this:
>>
>> #
>> # Now divert all inbound packets that should go through NAT. Since this
>> is NAT
>> # it can only match a packet that previously was NATted on the way out.
>> #
>>         ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif}
>> #
>> # Check stateful rules; we want to go there directly if there is a match
>> #
>>         ${fwcmd} add 7000 check-state
>> #
>> # Now pick up all *outbound* packets that originated from an inside address
>> # and put them through NAT.  We then have
>> # a packet with a local source address and we can allow it to be sent.
>> # Therefore, if the packet is outbound let it pass and be done with it.
>> #
>>         ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit ${oif}
>>>>    ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip}
>>         ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit
>> ${oif}
>>         ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif}
>>
>> Without the ">>" line I get nothing; the packets get to the gateway and
>> disappear.
>>
>> With the ">>" line I DO get the packets re-emitted on the internal
>> interface HOWEVER there is no translation to the internal interface IP
>> on the gateway box.  So what I see on the internal box is this:
>>
>> 11:19:16.369634 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags
>> [S], seq 292171178, win 8192, options [mss 1460,nop,wscale
>> 8,nop,nop,sackOK], length 0
>> 11:19:16.369662 IP 192.168.10.100.11443 > 192.168.10.40.60924: Flags
>> [S.], seq 3088872007, ack 292171179, win 65535, options [mss
>> 1460,nop,wscale 6,sackOK,eol], length 0
>>
>> Which won't work because the internal box got and sent this:
> What is the NAT command running at instance 100?
> Does it have an -alias_address of inside IP of router?
> Are you tryint to use the same Nat instance to do both
> the global internet acess translation and this special
> inside loop back translation?  If so that usually can
> not be made to work.
Aha.  That's probably the problem -- I need a second instance.

Here's the entire salient section:


# Set up the NAT configuration; there are multiple entries that have to
be here
# because we redirect a bunch of ports around so we can see things from the
# outside -- specifically, webcams and the HomeDaemon server.
#
        ${fwcmd} nat 100 config ip ${oip} log same_ports reset
redirect_port tcp.... (whole bunch of stuff)

#
# Stop spoofing
#
        ${fwcmd} add 2010 deny log all from ${inet} to any not ipsec in
via ${oif}
        ${fwcmd} add 2020 deny log all from ${onet} to any in via ${iif}
        if [ -n "$inet6" ]; then
                ${fwcmd} add 2040 deny all from ${inet6} to any in via
${oif6}
                if [ -n "$onet6" ]; then
                        ${fwcmd} add 2050 deny log all from ${onet6} to
any in \
                            via ${iif6}
                fi
        fi

        ${fwcmd} add 3000 deny log all from ${onet} to any recv ${iif}

#
# This table is a list of denied addresses that tried to attack us.  Updated
# by sshguard.  Anything coming inbound from the outside is blocked.  We
also
# block anything on the "screw you" lists (two)
#
        ${fwcmd} add 4000 deny log all from table\(22\) to any recv ${oif}
        ${fwcmd} add 4010 deny all from any to ${foscam}
        ${fwcmd} add 4020 deny log all from ${china} to any via ${oif}
#
# Anything related to RFC1918 or the Manning range that comes in on
# the external interface (shouldn't happen) gets tossed immediately, EXCEPT
# for RFC1918 stuff coming in via IPSEC.  That we must pass or our IPSEC
# gateway will not work.
#
        ${fwcmd} add 5000 deny log all from ${rfc1918} to any not ipsec
recv ${oif}
        ${fwcmd} add 5010 deny log all from ${manning} to any recv ${oif}

#
# Now divert all inbound packets that should go through NAT. Since this
is NAT
# it can only match a packet that previously was NATted on the way out.
#
        ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif}
#
# Check stateful rules; we want to go there directly if there is a match
#
        ${fwcmd} add 7000 check-state
#
# Now pick up all *outbound* packets that originated from an inside address
# (including IPSEC tunneled stuff) and put them through NAT.  We $then have
# a packet with a local source address and we can allow it to be sent.
# Therefore, if the packet is outbound let it pass and be done with it.
#
        ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit ${oif}
        ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip}
        ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit
${oif}
        ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif}

From the above I assume I need to direct 8001 through a nat 200, and
define that as "twist anything that comes through there to be aliased
from the INTERNAL IP address", yes?

So I changed the above to be this:
      
       ${fwcmd} add 8000 nat 200 ip4 from 192.168.0.0/16 to ${oip}
       ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to any xmit ${oif}

So the first one would catch any inside packet that was headed to the
outside IP before the other gets ahold of it.

And added:

    ipfw nat 200 config ip ${iip} same_ports reset

Up above for the second NAT channel; "iip" is the gateway's internal IP
address.

But that winds up doing nothing; I get no packets back out on the inside
interface at all (just as if the "200" nat stuff was not there at all)



>> 11:19:16.369337 IP 192.168.10.40.60924 > 70.169.168.7.11443: Flags [S],
>> seq 292171178, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK],
>> length 0
>> 11:19:16.369433 IP 192.168.10.40.60925 > 70.169.168.7.11443: Flags [S],
>> seq 2666765817, win 8192, options [mss 1460,nop,wscale
>> 8,nop,nop,sackOK], length 0
>>>> 11:19:16.369502 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags
>> [S], seq 292171178, win 8192, options [mss 1460,nop,wscale
>> 8,nop,nop,sackOK], length 0
>>>> 11:19:16.369511 IP 192.168.10.40.60925 > 192.168.10.100.11443: Flags
>> [S], seq 2666765817, win 8192, options [mss 1460,nop,wscale
>> 8,nop,nop,sackOK], length 0
>>
>> But since the gateway emitted the packet back on the wire *without*
>> remapping the source address (to itself) it doesn't match on the client
>> box 'cause there's no way back for it.
> Yep.
>
>> There has to be a solution to this somewhere and I'm obviously missing
>> it..... :)
>>
>> -- 
>> Karl Denninger
>> karl at denninger.net <mailto:karl at denninger.net>
>> /The Market Ticker/
>> /[S/MIME encrypted email preferred]/
> This is the classical "Loopback Nat Problem" of accessing machines
> behind a NAT device that does not do the proper NATTing and 
> routing of these packets.   Many small consumer routers got this
> wrong for years, just like most ipfw code I have seen.
>
> Most of the consumber devices have been fixed.  The trickery is
> you need to NAT packets coming from the inside destined for the
> outside IP into the internal IP.  That internal box MUST route
> back via the NAT device, so the NATTED addresses for these
> packets must be the inside IP of the router.
>
> Your code looks to get this mostly right, but I think you have
> missed something someplace.  I dont use kernel nat, and it looks
> like you do so you well have to adjust these a little.
>
> inside_ip_router="192.168.10.40"
> outside_ip_router="70.16.10.1"
> inside_ip_webserver="192.168.10.100"
>
> #natd-vmxZ.conf should just be an empty file for this type of nat
> /sbin/natd -f /etc/firewall/natd-vmxZ.conf  -port 8888 -alias_address ${192.168.10.40} 
>
> Something like
> # This takes inside traffic to outside port 80 address and
> # remaps it to inside IP of router to send to web server
> ${fwcmd} add X divert 8888 tcp from 192.168.0.0/24 to ${outside_ip_router} port 80
> # This translates the returning packets
> ${fwcmd} add X divert 8888 tcp from 192.168.0.0/24 port 80 to ${inside_ip_router}
>

-- 
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/20170504/96087cbb/attachment.bin>


More information about the freebsd-ipfw mailing list