[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [FW1] problem - same reserved addressing on networks and VPN tunneling
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: davidxs [mailto:[email protected]] > 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 ================================================================================
|