| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| Let me set the scene.... Network 1-----FW1----------VPN------FW2----------Network 2 10.10.10.x-----20.20.20.x----VPN------82.82.82.x----10.10.10.x (objects in red are my objects) The two firewalls are in a VPN configuration, FW1 has a subnet the same as FW2. My understanding of best practice would be to NAT Network 2. If I NAT to an address, say of 10.120.130.3 translate the object (I'm using NG FP3), set a virtual interface on the incoming 82.82.82.x interface on FW2 of 10.120.130.x. Would this be right? Then I would have thought FW1 needs a route adding for 10.120.130.x ? Your advice would be appreciated. __________________ Remember to add to someones reputation if they have helped you, by clicking on their scales icon |
| |||
| There is a pdf on the check point site that explains exactly what to do when having an overlapping IP range like this. I am guessing here that you own FW2 but FW1 is a 3rd Party. In which way to you want to connect between the two networks as it makes a difference as to the work required on FW2. If you wish to connect to them as I am guessing then you will need to Hide NAT your Network2 behind another address and ensure that FW2 will respond to that address. FW1 will need to NAT Servers that you are wanting to connect too behind other IP addresses and you will connect to the NATted addresses. You will tell FW2 that the encryption domain for FW1 is the NATted addresses. If you connect to a 10.10.10.x then you will talk to a local machine and not goto FW2 in the first place. FW1 will be told that the Network2(NATted) address is the encryption domain for FW2. As the FW1 and FW2 will have a VPN then they will effectively gain a route by knowing that the remote encryption domain is and is via the remote gateway. You do not need to manually add routes to do this. In short if imagine that FW1 is natting 10.10.10.20 behind 10.120.120.20 then a machine in network 2 will initiate a connection to 10.120.120.20. It arrives at FW2 and is NATted behind 10.120.130.3. FW1 sees a packet arrive from 10.120.130.3 and destined for 10.120.120.20. It then recognises needs to NAT the 10.120.120.20 to 10.10.10.20 and forwards on. The Network1 Server sees the packey comes from 10.120.130.3 and routes the reply back to the FW1 which then NATs the reply so says comes from 10.120.120.20 destined for 10.120.130.3. This goes down the VPN to FW2 which then translates the destination back to the original Network 2 address and forwards back out. |
| |||
| Exactly, the tunnel seem to be functional however when the 3rd party fw1 tries to contact the NAT'd IP 10.120.130.4 for example I see the following error: Quote:
-----ORIGINAL-------------------/-----TRANSLATED--------------- source----------destination----/source----------destination---- fw1 domain------Nat'd IP--------/original----------real IP(static)----------- real IP-------fw1 domain--------/Nat'd IP(static)----------original----------- I cant see what the problem is? __________________ Remember to add to someones reputation if they have helped you, by clicking on their scales icon Last edited by daz306td; 2007-10-02 at 04:37. |
| |||
| newbie mistake! The Nat'd IP wasnt added within my local encryption domain doh! Works perfect now! __________________ Remember to add to someones reputation if they have helped you, by clicking on their scales icon |
![]() |
| Thread Tools | |
| Display Modes | |
| |