Check Point Mobile VPN issue

[alan_garnham]

Hi all

I've set up our Sydney 12200 Check Point FW as a VPN GW for remote users.

The FW communicates with our RSA ACE and this is working well

Test users can authenticate and obtain the VPN IP address, also performing a"route print" the laptops have learnt all the internal routes.

The issue is the laptops cannot access the internal network and the FW logs do not show any traffic from the laptops to the destination. Performing a tracert to an internal destination fails at first hop.

The Sydney FW has the correct static routes configured and itself can access internal networks.

Any help would be appreciated.

[PhoneBoy]

Surely when the VPN clients connect and authenticate, there are logs, correct?

Also, have you done a tcpdump when a VPN client tries to communicate to:

• See if the packets actually leave the Security Gateway
• See if there are any responses received to said packets (e.g. ping)

I suspect the issue is the rest of your network doesn't know where to direct the reply packets for your VPN clients.

Depending on your exact topology and the Office Mode IPs, we can provide a bit more specific advice.

[Vladimir]

The obvious question: do you have access rules permitting your remote clients communication with internal networks?

If you are not seeing the attempts in the logs, you likely have a cleanup rule with "drop" and "do not log" in your policy that behaves as it should. Enable logging on it for troubleshooting to see the drops.

There are also Implied rules that are not logged that you can enable logging in the "Global" properties for troubleshooting.

Do remember to change those back to "do not log" to avoid flooding your log server.

[alan_garnham]

Hi Dameon and Vladimir

Thanks for getting back to me.

Using FW monitor and tcp dump there are no packets when generating traffic. There are packets where the VPN client is communicating to the FW on rule 0 but these packets are generated whether or not the client is trying to communicate inside.

The FW's have the correct routes to the inside network and the policy permits the traffic.

[Vladimir]

Kindly paste the subset of the rulebase you have defined for VPN in this thread.

It would also help to see the diagram of the network you are working with as well as a printout of active routes.

As to a traceroute, enable "Accept ICMP" in the global properties to see the traversal of the firewall.

[alan_garnham]

Hi Vladimir

The basic diagram attached

The policy for our Mel and Syd are shared by the FW’s thus there is only one policy for both.

Mel VPN uses the rules below

ICMP

Everything else

I’ve enabled #Accept ICMP” in the global properties now and installed the policy

Regards

Alan

[PhoneBoy]

A version of the diagram as a PDF or JPG would be preferable.

Also keep in mind this is a public forum and you may wish to mask sensitive data.

[alan_garnham]

Hi Vladimir

Below are the only traffic logs generated – tunnel tests. 10.128.99.21 is the Mgmt interface and not the inside interface.

[Vladimir]

1. Please verify that the server 10.8.251.187 has a return route to the IP Pool on Syd Firewall. Run traceroute on it to see where it goes.

2. Please verify that the Mel VPN is NOT active on the remote user's laptop at the time of the test and that there are no residual or static routes present on it that may skew the test.

3. You have common VPN community servicing both gateways for the same destination. Is that community configured as MEP (Multiple Entry Points)?

4. The logs you are looking at may be filtered, please remove filters if any present.

5. If the community is not a MEP, consider creating a separate community by cloning "Remote Access" and creating two sets of rules for VPN with target gateways defined in each rule.

6. Your 10.0.0.0/8 route is too broad and includes your IP Pools. It'd be cleaner to have a different range for Remote Clients, such as 172.16... or 192.168.255... (just NOT 192.168.0.0 or 192.168.1.0).

7. Check if your Syd "CP_default_Office_Mode_addresses_pool" or whatever network you have defined for it is NATed to hide behind gateway. Compare to Mel.

[alan_garnham]

Thanks Vladimir

Some excellent points to investigate.

1. 10.8.251.187 routes correctly via Syd FW for 10.15.16.x

2. Mel VPN is removed from the client VPN so is not active at the time of the tests.

3. Good point, I will investigate this.

4. Good point, I will investigate this

5. Good point, I will investigate this

6. Agree.

7. Good point, I will investigate this

Regards

Alan

[alan_garnham]

Hi Vladimir

The RemoteAccess community is a star topology with no way to prevision MEP, see below

I cannot clone this community, copy is available though.

Another colleague stated they could access the network from their home computer with the VPN client installed.

I am going to try the same when I get home tonight.

Regards

Alan