Unable to connect to remote office with SecureRemote

[cpthrow]

Hi,

I am trying to connect to other internal networks, that are connected to each other through VPN, with out success. Here is our current architecture:

Main gateway and SMS are NGX R61. All remote access using SecureRemote connects here. Network 192.168.6.0

The two remote offices are using edge boxes and have VPN connections to each other as well as the main gateway. Networks 192.168.2.0 and 192.168.3.0

The VPN for all 3 sites are mesh connected and all subnets are visible to each other.

Here is the problem, when I connect to the main gateway through SecureRemote/Client, I can see and access hosts on the main gateway, 192.168.6.0. However, I can not see any of the hosts on either of the other two networks, 192.168.2.0 or 192.168.3.0. The only way I can access the other networks is jump from a host on the 192.168.6.0.

I did notice that when going to the other 2 networks, the ip is not routed through the the remote VPN, but rather my internet provider. I manually added a default route of one of the other local networks so that it goes through the VPN client. Traffic did go through SecureRemote, but stopped there.

First is this possible, to connect using either VPN Clients and traverse to other networks that are connected by VPN to the NGX 61 network?

Second, do I need SecureClient and a local static IP address? I tried assigning a local IP on 192,168.6.0 and the traffic was dropped because of IP spoofing. Next I assigned an IP on another private network, 192.168.7.0, but that got back where I started. Able to see 192.168.6.0, but nothing on the other internal networks.

Thanks

[RayPesek]

Try adding 192.168.2.0 or 192.168.3.0 into the VPN domain and doing a site or topology update on SecuRemote.

Ray

[cpthrow]

Hi Ray,

I am still new to CheckPoint, but not sure what you mean by the VPN domain. Is this the site-to-site object, the main gateway object, or something else. Can you please point me were to set or edit.

Thanks

[cpthrow]

After looking around, under the target gateway object, I did see VPN Domain under topology. When I added 192.168.2.0 to the manually defined, that broke connectivity for any one on the subnet.

Did I edit in the wrong place?

Thanks

[RayPesek]

You need to do this on the "main gateway" where Securemote clients connect.

The VPN Domain defines what IP addresses behind the firewall can be reached by a VPN. In R61, it covers both remote access and site-to-site VPNs. In R65 you can define remote access and site-to-site VPN Domains separately.

You should create a group and add network objects into the group that define what needs to be reached by any VPN. Then set the VPN Domain to that group and install the policy.

My guess is you replaced what was there with the new one, which is what broke your connectivity.

Ray

[cpthrow]

Just some more background. The original policy came from R55 and probably earlier. The vpn is still in traditional mode, but we plan on moving it to simplified mode next week. I am not sure if that is what is effecting us now.

The VPN domain for the main gateway had a group under manually defined. That group has 2 local subnets, controlled by the main gateway. I left that out just to keep things simple. I created a new group with the 2 original subnets and added the subnet for the edge box. Also note that the SMS does not manage the edge box, but there is a checkpoint network object for the edge box. The edge box still had the subnet that I added to the main gateway, in it's VPN domain. Should that have come out?

A more accurate picture.

SecureRemote -> Main gateway -> vpn <- Edge not controlled SMS
192.168.6.0 Main gateway
192.168.7.0 192.168.2.0
|
v
vpn
^
|
Edge 2 not controlled by SMS
Main gateway
192.168.3.0




When I pushed the policy, the network behind the edge box was dead all together. It could not get out to the internet. I was able to connect to the gateway by SecureRemote using a network outside of ours. I then replaced the group with the original group that just had the 2 local subnets it controlled and things were back to normal.

One other thing I noticed, with in the main gateway object -> topology , there is a button that says set domain for Remote Access Community. when I click on this button, I get a response of "This Check Point is not a member of this Remote Access community" Could this be my problem as well.

I am in the process of cleaning our policy after years of neglect, and several software, hardware, and os updates. Thanks again for your help.

[cpthrow]

I was finally able to get this resolved. Here are the steps I took.

1) Convert to simplified VPN mode.

2) Create 2 new groups. First will contain networks for local lan controlled by main gateway and a network used for SecureClient using office mode.
e.g. VPNDomain 10.10.2.0 (local lan) 10.10.3.0 (network used for SecureClient).
Next create a remote vpn domain.
e.g. RemoteVPMDomain 10.10.2.0 (local) 10.10.20.0 (remote network)

3) Within the main gw object, under topology, set the VPN domain with networks for local lan to this object as well as a network for SecureClients using office mode (to assign local ip when connected.) This will be the VPNDomain group created above.

4) Set a remote access VPN domain, which will be different than the one set in step 3, This will contain local networks, as well as the subdomains controlled by the remote gateways that are connected by VPN to the main gateway. Do not add the subnet used for SecureClient. This will be the RemoteVPNDomain created above.

5) Add rules as needed.

Regards