From owner-freebsd-ipfw@freebsd.org Thu May 4 17:48:15 2017 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08942D5E10B for ; Thu, 4 May 2017 17:48:15 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EE33937 for ; Thu, 4 May 2017 17:48:14 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1493920090; l=5256; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=3WBOKFIVQgRJoOCajnkUDTXb0ub1tlnQriZe8WwiT9A=; b=iAAxMvD79H37eN4NglfhpgBhCSTcegvZ3dI7bD8cSODIwKDSn9Ai95IxoxswuS2l6U XqRyeIIvDUhcXNJdDE8JmLTLlNS2cTw4XYljnLgTRMmIiidRBhfnW37/hz6WHoeyQtts UwiVqCUlZdzYDcjlwPMDniu6pFiC7CqiQ9H60= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGhIn99HqS2s= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02aec2.virtua.com.br [187.2.174.194]) by smtp.strato.de (RZmta 40.6 DYNA|AUTH) with ESMTPSA id a04df1t44Hm8UJx (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Thu, 4 May 2017 19:48:08 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 19E817506DB2; Thu, 4 May 2017 14:48:05 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Question that has dogged me for a while. From: "Dr. Rolf Jansen" In-Reply-To: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> Date: Thu, 4 May 2017 14:48:03 -0300 Cc: freebsd-ipfw@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 17:48:15 -0000 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 : > 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 > /The Market Ticker/ > /[S/MIME encrypted email preferred]/