From owner-freebsd-ipfw@freebsd.org Thu May 4 16:58:56 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 072B3D5E461 for ; Thu, 4 May 2017 16:58:56 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0949C85 for ; Thu, 4 May 2017 16:58:55 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-qt0-x22f.google.com with SMTP id m91so15189617qte.3 for ; Thu, 04 May 2017 09:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dizhYutbaaEHbEkWDrtMfW1eS/KI/umN/zmrYZsGS2w=; b=ENdO8RCmVMWJWDRvcNdoRLgOpX7sckvDCsG57QSOdEaAnO2Pmdzug7F6vWlDGmLf4Q imhaqP22Mg4Z3S0gk3bWT9x4LeOiEgTOu+PS/A7L+cm30wgdPY15cXG0EQU0NcFoKD1h r5Kv+Ms56GYiiTrur2cWBXQbZ1ByiSxa8tldwbRj0gGDb9wz2LJAM6LpSKWCj0UAdKII 6+SbArbBzCqtpE7U+rQskd0vvojBXUsQBl+c0AbaOszpEIEj9FR9Jp/U4M1udXlom6Qt RqS7n4IAo0CjHr3bVRBIm1zYQq0kcoa+fEMz/XoUQ6BvpHvCq3gaCM9pwmtJu8yzr6gs F0ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dizhYutbaaEHbEkWDrtMfW1eS/KI/umN/zmrYZsGS2w=; b=cqqmqGTLo/OMGZlrB0ABu20uY63sBL0yzQ7U4nTQKN6BBFTTSw43VTVacbV+0yaOOk eBcX/z6x2sMLKZom5ynRrJ991Nn0z9q2mLpW+Qk2Rf1CaaSh3RUXIdrzuQy2SViC+PXG 3btg7AsfnDwI/etJc3HcmvpJfRjwdNumzWQCRYzR+M31Ehl1PPCdJBDeGLCL/rGAtWQ2 vWCxGQoPOUdRxhGHp5CSZNurS3KQYgE1TLyMY/iY6YEM0kC33WlWCxw3YtGoYJDSzUMJ bjrEP7OrfB/mQEgQlRL/lYg+S07j7GJpiVhnYrNuoFgJL/lfcJJ9W+MxO+etO6+dAXve B20A== X-Gm-Message-State: AN3rC/6dQHqOsltk8JbKBYVcC6RyFeGKg8RldlZBlJ2z6oYm4/yQIfxF bKjEmyV6jtnXAJJ2LXlNRAjITPAPqA== X-Received: by 10.200.52.165 with SMTP id w34mr13721810qtb.77.1493917134807; Thu, 04 May 2017 09:58:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.199 with HTTP; Thu, 4 May 2017 09:58:37 -0700 (PDT) In-Reply-To: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> From: Freddie Cash Date: Thu, 4 May 2017 09:58:37 -0700 Message-ID: Subject: Re: Question that has dogged me for a while. To: Karl Denninger Cc: "freebsd-ipfw@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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 16:58:56 -0000 On Thu, May 4, 2017 at 9:22 AM, Karl Denninger 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 addre= ss > # 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..... :) =E2=80=8BYou need to do a double-NAT (or hairpin-NAT or whatever you want t= o call it), where you first NAT the destination address on the incoming interface which will initiate the routing decision for where to send the packet next, then NAT the source address on the outgoing interface (which can be the same interface) in order to get the return packets sent back to the correct gateway. Something along the lines of: ipfw nat 100 blah blah blah ipfw nat 200 blah blah blah ipfw add nat 200 tcp from 192.168.0.0/16 to 70.16.10.1 80 in recv ipfw add nat 100 tcp from 192.168.0.0/16 to 192.168.1.1 80 out xmit ipfw add nat 100 tcp from 192.168.1.1 80 to 70.16.10.x in recv ipfw add nat 200 tcp from 70.16.10.1 80 to 192.168.0.0/16 out xmit