First of all, Thanks a lot for all the answers i received so quickly (Daryl,
James, Joshua, Steven, Brendan & all the others not quoted here).
I will try to make a global answer & give some more information.
- For those who suggest to use 10.0.0.0 from RFC 1597 :
As I knew this RFC, i agree with you, but when we chose our adressing plan,
this wasn't really published. With the recent growth of our private
IP network, it would represent a really hard task to renumber
the entire newtwork.
It won't be a problem anymore when we will use DHCP and WINS
everywhere :) .
- For those who suggest some adress based translators (NSC, ...):
As you mentioned, they are not able to manage the IP
adresses that are not in the IP header but in the data part,
can some of you make comments about that (which protocols are
problematic, ..) ?
- For those who suggest to use proxy based firewalls (Borderware, ANS,
...), we already use one, it is a TIS based firewall (just guess
which one :) ).
What i want to add is that the problem doesn't come from the use
of a filter packet based or proxy based firewall.
It comes from the implementation of the standard IP layer, which
is used in all firewalls products (as far as i know).
The firewalls use the IP layer included in the UNIX OS, even if
modified in some way (no IP forward, no IP redirect ...).
BUT, for this IP routing layer, an IP adress can only exist
on ONE interface.
Example :
You define a IP subnet "S" on your Intranet that already exist
on the Internet.
A station from S on the Internet want to connect
to your firewall.
If the IP layer of the firewall sees a packet with the S
IP adress coming from the external Ethernet adapter, then it
will decide it is some kind of IP spoofing attack, and reject it.
One solution to this proble could be that the IP layer is able
to manage couples (IP adress A , adapter 1) and (IP adress A, adapter 2),
instead of IP adress A -> adapter .
The A adress from adapter 1 could be considered as trusted and
the one from adapter 2 untrusted.
I know this not a "politically correct" routing mecanism, but a firewall
is not supposed to be a standard IP host.
Now, a station from S on the Intranet wants to connect to a
server which is also in the S subnet on the Internet.
The packet arrives OK to the internal adapter and the proxy application,
but when it goes again from the proxy, the IP layer routes it back to the
Intranet instead of the Internet.
Why not suppose that if a packet comes from the Intranet (internal
adapter) , then it means that it wants to "go out" (external adapter)?
What's the use of making a round trip from Intranet to Intranet?
You may think that the probability of such a case if very small,
but our problem is we don't use just one S net, but S1, S2, S3,.. nets.
The more our network expands, the more B class we use from the Internet
that become unreachable (once defined as trusted in the firewall, it
can no longer appear on the Internet side).
With this information, can you still confirm me that there are
(and which ones ?) firewall products able to handle that problem ?
Thanks for your patience!
Marc.
For those who didn't read Chapter 1, here is my question :
>Hi, our private Intranet adressing plan is using several class B that are
already
>allocated on the Internet, as our Intranet was created long before we
planned to interconnect
>with the Internet.
>We use a single firewall which masks our private adresses, but we are not
able to reach
> the public portion of the Internet that uses the same IP adresses.
>The only solution i know to handle that problem is to use 2 firewalls
serialized
>with a pseudo network between the Intranet and the Internet.
>Does anybody knows a product able to solve this problem with only one
firewall ?
>Thanks in advance.
>
=========================================================================
|| Marc Rapoport : rapoport @
iway .
fr ||
|| AGF.SI Tour Franklin - La Defense 8 ||
|| 92042 PARIS LA DEFENSE CEDEX ||
|| Tel : 49.03.31.77 Fax : 47.67.07.90 ||
=========================================================================
Follow-Ups:
|
|
