From owner-freebsd-current Thu Feb 24 4:58:23 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.ucb.crimea.ua (UCB-Async4-CRISCO.CRIS.NET [212.110.129.130]) by hub.freebsd.org (Postfix) with ESMTP id 42E3237BBDB for ; Thu, 24 Feb 2000 04:58:00 -0800 (PST) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) id OAA17950; Thu, 24 Feb 2000 14:55:46 +0200 (EET) (envelope-from ru) Date: Thu, 24 Feb 2000 14:55:46 +0200 From: Ruslan Ermilov To: arnee Cc: freebsd-current@FreeBSD.ORG Subject: Re: natd, firewall, and RFC1918...? apologies! Message-ID: <20000224145546.A4465@relay.ucb.crimea.ua> Mail-Followup-To: arnee , freebsd-current@FreeBSD.ORG References: <38B50B92.2D399CA3@geocities.com> <38B5206E.E84E7AC3@geocities.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <38B5206E.E84E7AC3@geocities.com>; from arnee on Thu, Feb 24, 2000 at 04:13:34AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Feb 24, 2000 at 04:13:34AM -0800, arnee wrote: > sorry, i'm suppose to post this under freebsd-questions. this should teach > me posting early in the morning :-) > > To continue the questions... if the sample ipfw rule "deny all from any to > 192.168.0.0/16 via outside_interfaces" doesn't always work. Should it be > included in the rc.firewall example? > Please see PR conf/13769 for the same problem and a possible workaround. Note, that: : After translation by natd, packets re-enter the firewall at the rule : number following the rule number that caused the diversion (not the : next rule if there are several at the same number). Depending on the actual config, there could be a clean solution for this problem. For example, I use dedicated IP number for NATD, and my NATD rules look very close to the following: # Outside interface ruleset ${IPFW} add 50000 skipto 60000 ip from any to ${ALIAS_IP} in ... # Stop RFC1918 nets usage on the outside interface ${IPFW} add reject log ip from ${RFC1918_A} to any ${IPFW} add reject log ip from ${RFC1918_B} to any ${IPFW} add reject log ip from ${RFC1918_C} to any ${IPFW} add deny log ip from any to ${RFC1918_A} ${IPFW} add deny log ip from any to ${RFC1918_B} ${IPFW} add deny log ip from any to ${RFC1918_C} ... # IP de-aliasing ${IPFW} add 60000 divert natd ip from any to ${ALIAS_IP} in # Deny & log everything that isn't de-aliased ${IPFW} add deny log ip from any to ${ALIAS_IP} in # Pass all that is de-aliased ${IPFW} add allow ip from any to any in Also, the description of how packets re-enter firewall filter provided in etc/rc.firewall is obsoleted and should be replaced to match the reality. I will fix that. If you have something to say further, please followup on PR 13769. > arnee wrote: > > > I have been wondering what the right answer to this scenario is. Here is > > the scenario: > > > > machine A -- outside ip (internet) > > machine B -- router, natd, registered ip and set to stop RFC1918 on the > > public interface > > machine C -- inside LAN, unregisterd ip 192.168.0.0/16 > > > > When I connect to machine A from machine C, machine B (natd) seems to > > translate the addresses correctly like this: > > > > Out [TCP] "machine C's ip" --> "machine A's ip" aliased to > > [TCP] "machine B's ip" --> "machine A's ip" > > > > but when the packet comes back in, I get this: > > > > In [TCP] "machine A's ip" --> "machine B's ip" aliased to > > [TCP] "machine A's ip" --> "machine C's ip" > > ^ ^ ^ ^ ^ ^ ^ ^ > > > > and this brakes my ipfw rule of: > > > > "deny ip from any to 192.168.0.0/16 via outside_interface" ... which is > > part of the example from rc.firewall "stopping RFC1918 on the public > > interface." So, I always just delete this rule to get the packet inside > > the LAN. > > > > questions are: > > > > 1. Is this right? Is natd behaving correctly when the packet comes back > > in for unregistered ips? I would think that it would be aliased to like > > this, "machine B's ip" --> machine C's ip".... like a proxy? But this > > would still break the rule "... from any ...". > > 2. If so, is it correct to not include the ipfw rule above when stopping > > RFC1918? Better yet, what is the correct way of writing the rule? > > > > correct me if my assumptions are wrong. > > > > using 4.0current-2000.02.14 > > --- > > arnee -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank, ru@FreeBSD.org FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message