Date: Sat, 6 May 2017 03:33:30 +0800 From: Julian Elischer <julian@freebsd.org> To: "Dr. Rolf Jansen" <rj@obsigna.com>, Karl Denninger <karl@denninger.net> Cc: freebsd-ipfw@freebsd.org Subject: Re: Question that has dogged me for a while. Message-ID: <6f304edb-ad2e-cb2a-eea9-7b6bbe0be760@freebsd.org> In-Reply-To: <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>
> In unbound.conf you would place two additional lines before any forwarding directive:
>
> local-zone: "example.com" transparent
> local-data: "www.example.com" A 192.168.1.1
>
> All the clients on the LAN should use the DNS service on the gateway. In the first place Unbound does higher level DNS lookups locally, however, the transparent attribute lets it fall through to its normal recursive or forwarding behaviour in case a given domain could not be resolved locally. For example, the query of www.example.com would return 192.168.1.1 and the query for mail.example.com would be passed either to the forwarder or resolved recursively from the internet.
>
> By this way, local clients would directly access your web server from the inside, no NAT is needed.
>
> IMHO, a DNS server on the gateway got more advantages. It can be used to block access to fraudulent or otherwise useless services on the internet for the whole LAN.
>
> Best regards
>
> Rolf
>
>
> Am 04.05.2017 um 13:22 schrieb Karl Denninger <karl@denninger.net>:
>
>> 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:
>>
>> 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.
>>
>> There has to be a solution to this somewhere and I'm obviously missing
>> it..... :)
>>
>> --
>> Karl Denninger
>> karl@denninger.net <mailto:karl@denninger.net>
>> /The Market Ticker/
>> /[S/MIME encrypted email preferred]/
> _______________________________________________
> freebsd-ipfw@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6f304edb-ad2e-cb2a-eea9-7b6bbe0be760>