From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 8 10:12:42 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9F2B16A4CE for ; Mon, 8 Nov 2004 10:12:42 +0000 (GMT) Received: from mailomat.net (f-1.mailomat.net [217.110.117.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 061C043D46 for ; Mon, 8 Nov 2004 10:12:42 +0000 (GMT) (envelope-from noses@noses.com) X-Mailomat-SpamCatcher-Score: 2 [X] Received: from [194.39.192.125] (account bnc-mail@mailrelay.mailomat.net HELO bnc.net) by mailomat.net (CommuniGate Pro SMTP 4.2) with ESMTP-TLS id 2557581 for freebsd-ipfw@freebsd.org; Mon, 08 Nov 2004 11:12:39 +0100 Received: by bnc.net (CommuniGate Pro PIPE 4.2b2) with PIPE id 776101; Mon, 08 Nov 2004 11:12:39 +0100 Received: from [194.39.192.247] (account noses@noses.com HELO [194.39.192.247]) by bnc.net (CommuniGate Pro SMTP 4.2b2) with ESMTP-TLS id 776099 for freebsd-ipfw@freebsd.org; Mon, 08 Nov 2004 11:12:33 +0100 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Noses Date: Mon, 8 Nov 2004 11:12:32 +0100 To: ipfw-mailings X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Please contact info@mailomat.net for more information (colossus) X-MailScanner: Found to be clean Subject: Re: nat + forwarding == routing error??? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2004 10:12:42 -0000 > I've got a slightly complicated problem. I'm running a router with > multiple outgoing connections and a number of LANs and a DMZ being > routed through it. > > 1) Even though I have "fwd " rules for all > addresses I have to have a default router or the rules won't even be > reached (giving me a "no route to host" - I'd assume there should be a > way to force a packet to get into ipfw even if the kernel is believing > the packet would go nowhere. > > 2) Strangest problem: It depends on passing through natd whether a fwd > rule is behaving according to the man page or not. I've got the > following construction: > > divert ${NAT_1} all from 192.168.160.0/24 to any in via ${nic_LAN} > fwd ${Provider_1} all from ${DMZ_Provider_1} to any not ${local} > fwd ${Provider_1} all from ${NAT_addr_1} to any not ${local} > > The relevant NATD is using an "alias_address" statement (if there is > any difference). Extending the rules by "log" statements shows packets > being caught by the correct rules and tcpdump shows the packets on the > wire having been treated correctly by NAT. > Now packets from DMZ_Provider_1 are being sent to the correct outgoing > interface (which is different from the default route's interface) but > the packets that have been aliased by natd are sent out on the default > route even though the log shows me that the relevant "fwd" rule has > been taken. > > Any ideas? I always assumed that the knowledge about packets having > been treated by NAT would be kept inside natd... I have to admit that doing serious things after not having slept for 24 hours is not a good idea. My observation was wrong: The second fwd rule is applied and the packet is leaving the machine nut it is acting like a "permit" rule (i.e. the forwarding part is ignored). Which is just as bad but probably easier to explain. Achim