[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [FW1] NAT across a VPN
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Someone else had posted this question recently. My response was: - ---8<--- 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(10.10.10.0)---FW1a-----(Internet/VPN)-----FW1b---RemoteNet(10 10.10.0) (MyFake: 192.168.10.0) (RemoteFake: 192.168.20.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. Encryption domain for firewall A is a group containg LocalNet and MyFake. Encryption domain for firewall B is a group containg 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 10.10.10.0, dest IP 192.168.20.0 are translated on your firewall to src 192.168.10.0 dest 192.168.20.0. On the remote firewall they get translated from src 192.168.10.0 dest 192.168.20.10 to src 192.168.10.0 dest 10.10.10.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. You also need to create Static translations for the servers you need to reach, and create objects in your firewall that contain the RemoteFake IP addresses of the other servers. (This is in addition to the networks). Does appear to be do-able? Anyone care to comment? Regards, Frank > -----Original Message----- > From: Jon Vandiveer [mailto:[email protected]] > Sent: Thursday, October 05, 2000 7:11 AM > To: [email protected] > Subject: [FW1] NAT across a VPN > > > > I read Frank's post and while I am testing this in our lab I > wanted to see > if anyone had come up with a solution already. > > Problem: > local-net 10.10.10.0 > partner-net 10.10.10.0 > IKE VPN > > Is it possible to NAT either you or your partner -net, BEFORE > or after it > crosses the VPN ? > > Objective: > To allow a VPN between two companies without re-addressing > either company. > > Jon > > > Date: Wed, 4 Oct 2000 22:38:56 -0500 > From: Frank Knobbe <[email protected]> > Subject: RE: [FW1] VPN + NAT > > - -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > For these types of VPN's you probably want to add two Translation > rules that disable NAT for connections through the VPN tunnel. The > two rules are: > > MyNet - PartnerNet - Any - Original - Original - Any > PartnerNet - MyNet - Any - Original - Original - Any > > Make sure you set routes in your network that directs traffic aimed > at the PartnerNet to your firewall. > > Regards, > Frank > > > > > ============================================================== > ================== > To unsubscribe from this mailing list, please see the > instructions at > http://www.checkpoint.com/services/mailing.html > ============================================================== > ================== > -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.1 Comment: PGP or S/MIME encrypted email preferred. iQA/AwUBOd0Qq0RKym0LjhFcEQIXRQCdH74Y2YP1jp+/+X6edhnHNqCWVcYAoK5R BuySDWHcSGc4vFxkbXMIEevs =8lUz -----END PGP SIGNATURE----- ================================================================================ To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================================================
|