| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| I have a central Check Point VPN-1 gateway with a VPN community which has all my UTM-1 Edges. Now I have to connect two partner companies with Edges, but unfortunately they use the same internal network (192.168.1.0/24) and I can't bring them to change that. What we need is access to a single system behind every Edge. I came up with creating two new networks with 172.17.10x.0/24 ip addresses, which are not used elsewhere. Then I defined these networks as encryption domain for the Edge object in SmartCenter. I also defined NAT rules for the Edges so that when I access the new NAT address, for example 172.17.101.4, it is translated on the Edge. So I can use different NAT networks for the Edges and they can keep their overlapping local networks, as they don't appear in the VPN. But here's the catch: It's a one-way-VPN! When I send packets from the central network to a NAT address, the packet is encrypted and decrypted properly and reaches to destination server after NAT on the Edge. A return packet is send but this one never reaches the sender, as it is send unencrypted. I think that VPN is done before NAT on the Edge. So the Edge doesn't know that a answer packet with this specific source and destination has to be encrypted, since only the destination network is defined for VPN as NAT hasn't taken place yet. I thought about defining the NAT network and the local network as internal encryption domain on the Edge using add vpn internal-encryption-domain ranges iprange 172.17.101.0-172.17.101.255 add vpn internal-encryption-domain ranges iprange 192.168.1.0-192.168.1.255 so that the Edge thinks that this packet has to be encrypted and afterwards performs NAT. Can anybody tell me if this is going to work or how I can accomplish my goal to have to locations with the same local network behind the Edge in the same VPN? |
| |||
| You could try that. I'm a little surprised that it's not statefully being NAT'ed & Encrypted back to you, but it is an awkward configuration you have. Are you at least seeing the traffic being NATed even though its not being encrypted? If it doesn't work then I'd suggest doing the NAT on the internal switch & not the Edge device. It should be fairly easy to write an ACL for it. __________________ Its all in the documentation. |
| |||
| I sorted things today: The packet is not encrypted, but NATed anyway. For my purpose, hiding the same local networks behind two Edges, I did the following: I created two Edge objects in SmartDashboard and attached a group with networks as encryption domain to them. These groups contain each the duplicate network (192.168.x.0/24) and the network that I want to use for NAT. With this configuration I'm able to access machines in the 192.168.x.0/24 network through a NAT ip on the Edges. And the traffic back is considered for encryption by the Edge, NATed and THEN encrypted with the NAT ip as source. The only catch is, that I can't use the 192.168.x.0/24 network in question anywhere else in my firewall since it's no known. Oh, funny side effect: a tunnel between my main site and the 192.168.x.0/24 network can be established. But it's established with the same Edge every time. I haven't figured out yet why, I suggest that it's the first Edge with this network in the objects_C |
| |||
| Ah you're probably on to something with that guess. Reading through your reply made me think of something. If you're only accessing one host and that host is on a different IP at each site, then you could probably get by with using the real IP of the host. Instead of adding the entire 192.168.x.x to the VPN domain, only add the host & now there's no overlap & no worries regarding NAT. __________________ Its all in the documentation. |
![]() |
| Thread Tools | |
| Display Modes | |
| |