-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

NAT can be made to work in a kind of hybrid-bridge situation. (Working entirely from
memory here)...

If you associate a real IP address with the external facing interface of the bridge
firewall, packets egressing to the Internet via this interface can be NATed to the 
address
used.

The nifty thing about doing it this way is that the device still acts as a bridge, 
appears
as a single-homed host on the network, and doesn't require the logical network to be
broken up.

i.e.

(Internet)-------[IP][NAT]<Bridge Firewall>-----(Internal Network)

logically looks like:

(Internet)-------(Internal Network)
~                         |
~                 <Bridge Firewall>

Here's the downer, and Darren if something could be done about this, it would be 
uber-cool.

If you associate the IP address with the internal interface you get the following the
following effects:
1./ A bridging-firewall that can be remotely managed, via internal or external 
networks as
required.
2./ Packets addressed to the firewall MUST pass the packet-filtering PRIOR to reaching 
a
network interface that will acknowledge packets.  Thus meaning the only way to attack 
the
external facing interface is from same the segment of network it is attached to (i.e. 
via
using MAC addressing).
3./ The downside is NAT.  If you MAP a rule to the IP address, now on the internal
interface, outbound NAT kind of works.  That is to say packets traversing the firewall
will have their IP addresses changed to match the MAP rule.  However when return 
traffic
arrives at the external interface the firewall/NAT does not recognise them, as as such
does not pass them through.

If item 3. could be sorted in some way, you would be able to deploy IPFilter based
appliances in to ANY existing network environment, without having to break up the 
logical
network segment (and thus causing network chaos, and loss of available addresses).

Thats all folks.

Ben

Darren Reed wrote:
| In some email I received from Carson Gaspar, sie wrote:
|
|>
|>--On Friday, June 14, 2002 6:41 PM +1000 Darren Reed
|><[EMAIL PROTECTED]> wrote:
|>
|>
|>>In the case I presented for the FTP proxy, there was no actual translation
|>>happening.  All that was being done is using the proxy to drive the state
|>>table in order to allow the appropriate connection(s).
|>
|>OK, so color me confused. If the NAT code is receiving the packet, and
|>processing it, why on earth can't it re-write the addresses? Or is this an
|>inbound/outbound packet path issue?
|
|
| Because bridges generally sit in the middle of a network where the same IP
| network addresses are being used on both sides and network to MAC address
| discovery is done using ARP.  Maybe if you linked the NAT code into the ARP
| code in some way, you could make NAT work on a bridge.
|
| Darren
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6-2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAj0MI4QACgkQn8E4KU427uV8oQCgkn/HhF/BnI9J2rgvB2zvsOoD
2NsAnRIeskgIknEwViXv0hQk4lL7RIXj
=2Wiz
-----END PGP SIGNATURE-----

Reply via email to