Date: Thu, 4 May 2017 14:48:03 -0300 From: "Dr. Rolf Jansen" <rj@obsigna.com> To: Karl Denninger <karl@denninger.net> Cc: freebsd-ipfw@freebsd.org Subject: Re: Question that has dogged me for a while. Message-ID: <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> In-Reply-To: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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.
>=20
>=20
> Internet ------- Gateway/Firewall ---------- Inside network (including =
a
> web host)
> 70.16.10.1/28 192.168.0.0/24 =20
>=20
> The address of the outside is FICTIONAL, by the way.
>=20
> 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.
>=20
> I have DNS pointing at "webhost.domain" @ 70.16.10.1.
>=20
> 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.
>=20
> This works fine for anyone on the outside. HOWEVER, anyone on the
> INTERNAL network cannot see the host.
>=20
> My NAT configuration looks like this:
>=20
> #
> # 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}
>=20
> Without the ">>" line I get nothing; the packets get to the gateway =
and
> disappear.
>=20
> 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:
>=20
> 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
>=20
> Which won't work because the internal box got and sent this:
>=20
> 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
>=20
> 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.
>=20
> There has to be a solution to this somewhere and I'm obviously missing
> it..... :)
>=20
> --=20
> Karl Denninger
> karl@denninger.net <mailto:karl@denninger.net>
> /The Market Ticker/
> /[S/MIME encrypted email preferred]/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?08BB50FC-510C-4FCF-8443-0BB16EA2D032>