RE: [FW1] problem - same reserved addressing on networks and VPN tunneling

[Frank Knobbe <FKnobbe@FW1-NOSPAMKnobbeITS.com>]

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

> -----Original Message-----
> From: davidxs [mailto:davidxs1@flashmail.com]
> Sent: Wednesday, September 27, 2000 4:19 PM
> 
> I have a problem
> 
> I need to connect my FW-1 4.0 to a remote firm's FW-1 4.1 via 
> VPN tunnet ala
> ISAKMP
> 
> The other firm is using the same reserved addressing 
> internally as I am.
> 
> Is there any configuration via FW-1 that can fix this problem?
> Nat??  
> 
> If not any recommendations as how to work around this???


Although I haven't run into that situation yet, here is my guess on
solving this (Others, please correct me where I'm wrong):

Diagram:

LocalNet(192.168.1.0)---FW1a-----(Internet/VPN)-----FW1b---RemoteNet(1
2.168.1.0)
(MyFake: 10.10.1.0)                               (RemoteFake:
10.10.2.0)

* The remote firewall is defined with its external IP address.
* Your network is defined with your IP network (NAT with your fake IP
range), object is named LocalNet.
* Also create a network object called MyFake with the fake network,
and a static mapping to your internal IP range (the reverse of above
object).
* The remote network is defined with a fake IP network, RemoteFake.

Your rule set describes:

LocalNet - RemoteFake - Any - Accept/Encrypt
RemoteFake - LocalNet - Any - Accept/Encrypt

You need to add entries to the NAT table like this:

LocalNet - RemoteFake - Any -to- LocaNet(static)[in essence, MyFake]
- - Original - Any
RemoteFake - MyFake - Any -to- Original - MyFake(static)[in essence,
LocalNet] - Any

The other firewall does the same. Same objects and rules (name
differently to avoid confusion). Now, packets with Src IP
192.168.1.0, dest IP 10.10.2.0 are translated on your firewall to src
10.10.1.0 dest 10.10.2.0. On the remote firewall they get translated
from src 10.10.1.0 dest 10.10.2.0 to src 10.10.1.0 dest 192.168.2.0.
In other words, machines on the remote network will need to be
addresses with their NATed addresses.

This should work for most, translatable protocols. However, you may
find protocols that do like this. NetMeeting conversations may fail
between these networks. Also, any protocol that uses internal
addresses to register clients with (such as a registration on an ILS
server, to stick with the NetMeeting example) will not work. It all
depends on what you need to transfer. NetBIOS traffic should work
fine, however, use static entries on your WINS server for remote
machines (using the fake addresses). WINS replication with the other
side will obviously mess things up.

Does appear to be do-able? Anyone care to comment?

Regards,
Frank




-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.1
Comment: PGP or S/MIME (X.509) encrypted email preferred.

iQA/AwUBOdKByURKym0LjhFcEQK8CwCeNZe6v4OExzSdp2GmZplzJaV54VIAn1zB
MU9yqXx46JCR7SwwwpZo+fDf
=oxH3
-----END PGP SIGNATURE-----


================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================