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
[EMAIL PROTECTED]        United Commercial Bank,
[EMAIL PROTECTED]          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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to