From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 19:50:06 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C443D1065670 for ; Mon, 26 Sep 2011 19:50:06 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7A25A8FC0A for ; Mon, 26 Sep 2011 19:50:06 +0000 (UTC) Received: by vcbf13 with SMTP id f13so4343338vcb.13 for ; Mon, 26 Sep 2011 12:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vG8uOPi4/46mBcC6WK1Yl3XtpDJc25NVUbSYLL5WZ9E=; b=IJ1ezb7raB+qZHOdhs89jDEFWLlJt/lBpDDsZrEhr/WDvT+Q8wiIkey/2RvGK5Uhwb MMzpsYC5DSuO5pmxiIf1ZAPs5jC3BT2cUEQdgQ5YOAALTzuPgnvhBn1ZRV2BhrTZ1yo/ MeYQv0P8rjrckXk1WM0qf0YBqYMl3yTJ3QHg8= MIME-Version: 1.0 Received: by 10.52.29.103 with SMTP id j7mr6705921vdh.235.1317064820533; Mon, 26 Sep 2011 12:20:20 -0700 (PDT) Received: by 10.220.198.130 with HTTP; Mon, 26 Sep 2011 12:20:20 -0700 (PDT) In-Reply-To: <4E7B450F.5050802@wp.pl> References: <4E412116.1070305@wp.pl> <4E422A74.3090601@wp.pl> <4E7B450F.5050802@wp.pl> Date: Mon, 26 Sep 2011 12:20:20 -0700 Message-ID: From: Freddie Cash To: Marek Salwerowicz Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ipfw - accessing DMZ from LAN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 19:50:06 -0000 On Thu, Sep 22, 2011 at 7:24 AM, Marek Salwerowicz wrote: > W dniu 2011-08-10 16:22, Freddie Cash pisze: > > >> The more correct method is to double-NAT the traffic, such >> that the LAN >> clients connect to public IPs, and the DMZ servers see >> connections from >> public IPs. It's more complicated to wrap your head around >> the first time, >> but it prevents private IPs from "leaking" between the LAN, >> the Internet, >> and the DMZ. (It took me 10 years of using IPFW to figure >> this one out.) >> >> # Configure the general natd process for the LAN >> natd -port $port2 -same_ports -use_sockets -alias_address >> x.x.x.171 >> >> # Configure the natd process to NAT from x.x.x.170 to >> 192.168.0.10 using >> some port >> natd -port $port1 -same_ports -use_sockets -alias_address >> x.x.x.170 >> -redirect_address x.x.x.170 192.168.0.10 >> >> # NAT the traffic coming from the LAN to x.x.x.170 >> ipfw add divert $port1 ip from $LAN to x.x.x.170 in recv vr0 >> ipfw add allow ip from $LAN to 192.168.0.10 in recv vr0 >> >> # NAT the traffic going to x.x.x.170 from the LAN >> ipfw add divert $port2 ip from $LAN to 192.168.0.10 out xmit vr2 >> ipfw add allow ip from x.x.x.171 to 192.168.0.10 out xmit vr2 >> >> # NAT the traffic coming from x.x.x.170 to the LAN >> ipfw add divert $port1 ip from 192.168.0.10 to x.x.x.171 in >> recv vr2 >> ipfw add allow ip from 192.168.0.10 to $LAN in recv vr2 >> >> # NAT the traffic going to the LAN from x.x.x.170 >> ipfw add divert ip from 192.168.0.10 to $LAN out xmit vr0 >> ipfw add allow ip from x.x.x.170 t0 $LAN out xmit vr0 >> >> The general flow of the rules above is (src --> dest) >> 10.0.0.x --> x.x.x.170 >> 10.0.0.x --> 192.168.0.10 (after first NAT) >> x.x.x.171 --> 192.168.0.10 (after second NAT) >> >> 192.168.0.10 --> x.x.x.171 >> 192.168.0.10 --> 10.0.0.x (after first NAT) >> x.x.x.170 --> 10.0.0.x (after second NAT) >> >> Notice how vr3 is never used in any of the rules above, as the >> packets never >> touch the public interface of the router. >> >> >> > Hi, > > I set up firewall like this: > > Your rules are too generic, they will not work for a double-NAT setup. Each and every single rule must specify the network interface. And it must specify whether it's incoming (in recv) or outgoing (out xmit) traffic. Don't use "via" anywhere. While it's easier to use generic rules to start with, you really need to get very specific, at least for the double-NAT setup. See my example above. -- Freddie Cash fjwcash@gmail.com