From owner-freebsd-questions@FreeBSD.ORG Sun Dec 14 21:26:00 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC69F16A4CE for ; Sun, 14 Dec 2003 21:26:00 -0800 (PST) Received: from tequila.4you.lt (tequila.4you.lt [212.122.68.216]) by mx1.FreeBSD.org (Postfix) with SMTP id B3AA243D32 for ; Sun, 14 Dec 2003 21:25:57 -0800 (PST) (envelope-from hugle@vkt.lt) Received: (qmail 53955 invoked by uid 0); 15 Dec 2003 05:22:50 -0000 Received: from hugle@vkt.lt by tequila by uid 82 with qmail-scanner-1.20rc1 (. Clear:RC:1:. Processed in 0.941498 secs); 15 Dec 2003 05:22:50 -0000 Received: from unknown (HELO hugl3) (213.252.192.162) by tequila.4you.lt with SMTP; 15 Dec 2003 05:22:49 -0000 Date: Mon, 15 Dec 2003 07:25:21 -0800 From: hugle X-Mailer: The Bat! (v2.01) X-Priority: 3 (Normal) Message-ID: <198144994821.20031215072521@vkt.lt> To: freebsd-questions@freebsd.org In-Reply-To: <20031215004603.GT64340@seekingfire.com> References: <20031214233809.GS64340@seekingfire.com> <20031215004603.GT64340@seekingfire.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re[2]: ipnat+ipfw + 3 gateways X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hugle List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2003 05:26:01 -0000 TH> On Sun, Dec 14, 2003 at 07:23:26PM -0500, fbsd_user wrote: >> What do you think IPF is? That's the utility name used to load >> filter rules into IPFILTER. >> So you are doing just what I said. The original poster said >> nothing about doing traffic shaping. >> IPNAT will not function with out IPFILTER rules. At lease pass in >> all on all interfaces. He listed none in his post. TH> Unlike IPFW, IPF defaults to "open" (thus the reason for the TH> IPFILTER_DEFAULT_BLOCK kernel option). Thus IPF won't be blocking any of TH> the packets that IPNAT is NATing. For example, when I issue a `ipf -F TH> a`, my IPNAT rules continue to function normally. TH> -T As for now my rules are default to allow. But I can't understand, why I can't use forward. As i know, NAT is done before forwarding, so firstly packets, get NAT'ed, and after they are forwarded to needed gateway. I had these king of rules in ipfw+natd using fwd rules. So I thought there is a must to use forward rule , but didn't find rule like forward in IPF. Actually it doesn't mather to me if it will be using ipnat+ipfw ar ipnat+ipf. THe main reason WHY i'm doing that is because of oidentd doesnt' work with NATD. but i've also heard that ipnat has better pperformanse as it runs in kernel space (not user space like natd do). now about this script. The result I came to (depending on this FAQ http://www.obfuscation.org/ipf/ipf-howto.html#TOC_1) was to just remove ipfw rules (default to allow) #gw2 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 53 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 6111 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 6112 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 6113 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 6114 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 6115 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 6116 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 6117 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 6118 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 6119 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 4000 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 7777 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 7787 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 7877 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 7887 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 27005 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 27015 -> 213.252.192.142/32 map vlan0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 27960 -> 213.252.192.142/32 #gw1 map fxp0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 22 -> 213.252.192.162/32 map fxp0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 25 -> 213.252.192.162/32 map fxp0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 79 -> 213.252.192.162/32 map fxp0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 81 -> 213.252.192.162/32 map fxp0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 110 -> 213.252.192.162/32 map fxp0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 443 -> 213.252.192.162/32 map fxp0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 2082 -> 213.252.192.162/32 map fxp0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 5050 -> 213.252.192.162/32 map fxp0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 5190 -> 213.252.192.162/32 map fxp0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 1863 -> 213.252.192.162/32 map fxp0 from 192.168.0.0/16 ! to 192.168.0.0/16 port = 6667 -> 213.252.192.162/32 map fxp0 from 192.168.0.0/16 to 213.226.139.46 port = 7000 -> 213.252.192.162/32 #all other traffic go via gw3 map rl1 from 192.168.0.0/16 ! to 192.168.0.0/16 -> 212.59.9.59/32 default route is: 213.252.192.161 in MY opinion these rules should WORK. but as it seems, they don't Any ideas? Thanks, Jarek