Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Feb 2000 02:44:34 -0800
From:      arnee <arnee@geocities.com>
To:        freebsd-current@FreeBSD.org
Subject:   natd, firewall, and RFC1918...?
Message-ID:  <38B50B92.2D399CA3@geocities.com>

next in thread | raw e-mail | index | archive | help
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



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?38B50B92.2D399CA3>