Date: Thu, 24 Feb 2000 14:55:46 +0200 From: Ruslan Ermilov <ru@ucb.crimea.ua> To: arnee <arnee@geocities.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: natd, firewall, and RFC1918...? apologies! Message-ID: <20000224145546.A4465@relay.ucb.crimea.ua> In-Reply-To: <38B5206E.E84E7AC3@geocities.com>; from arnee on Thu, Feb 24, 2000 at 04:13:34AM -0800 References: <38B50B92.2D399CA3@geocities.com> <38B5206E.E84E7AC3@geocities.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000224145546.A4465>