Very Computer

I have lately come across the following problem which I have been unable to
resolve. If someone can give me some hint(s) it would be greatly
appreciated.

Imagine a company network with unregistered addresses (say 192.168.0.0)
which connects to the Internet via a multi-homed FreeBSD box and a permanent
connection. It is quite apparent how you can set up the FreeBSD machine to
divert packets from the internal net to natd for translation as well as
impose filtering rules to incoming packets from the internet. However it is
not apparent how to control packets from internal machines accessing the
internet. Since the divert rules appear first in the ipfw ruleset, all the
following rules apply to the _translated_ packets (i.e. with the alias IP
address) once re-injected in the rule stream by natd. I.e. all internal
machines have the same "permissions" as the gateway/firewall machine.
Supossing telnet access is generally forbiden but for host 192.168.2.1 while
(of course) masking the host's virtual IP address, how is this achieved?

Thanks in advance,

Dr. K. J. Dryllerakis

Quote:

> Imagine a company network with unregistered addresses (say 192.168.0.0)
> which connects to the Internet via a multi-homed FreeBSD box and a permanent
> connection. It is quite apparent how you can set up the FreeBSD machine to
> divert packets from the internal net to natd for translation as well as
> impose filtering rules to incoming packets from the internet. However it is
> not apparent how to control packets from internal machines accessing the
> internet. Since the divert rules appear first in the ipfw ruleset, all the
> following rules apply to the _translated_ packets (i.e. with the alias IP
> address) once re-injected in the rule stream by natd. I.e. all internal
> machines have the same "permissions" as the gateway/firewall machine.
> Supossing telnet access is generally forbiden but for host 192.168.2.1 while
> (of course) masking the host's virtual IP address, how is this achieved?

I would suggest modifying the /etc/rc.firewall script to put the divert
rule after the filtering rules for your network.  That way you can apply
any filtering you want before the translation occurs.

- K.C.

    Unfortunatelly, only "deny" rules will have any effect before the
"divert" rule since a succesful "allow" rule will terminate the search
without diverting the packet. There must be another method to control were
the packets are re-injected in the rules for filtering. I just can't figure
out what it is...

KD