• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 624
  • Last Modified:

Unable to connect to VPN via Checkpoint secureclient 500pts

have remote access users coming in via our own adsl connection. These users are then allocated an address from the range 192.168.1.x
The router is a linksys router.

They then use checkpoint secureclient to connect to the lan via vpn.

All these users, apart from one are unable to connect via this method, however,
We have one user who CAN connect via this adsl.

All the users CAN CONNECT when they come in via THEIR OWN dialups or adsl.

1. Any ideas as to why the users can't connect to the vpn when using the  company adsl connection, yet one user CAN & has apparently the same settings?

Is this anything to do with Nat traversal ? How can I fix this?

I've also asked this in firewall section!

  • 4
  • 3
1 Solution
Rob WilliamsCommented:
The local and remote subnets must be different. Is there any chance that the main office to which these users are connecting is also 192.168.1.x  If so, the subnet at one end or the other will need to be changed to something like 192.168.2.x.
The one user connecting may have the checkpoint client configured slightly differently with the VPN default gateway allowing them to connect even if the subnets are the same.
I assume you have tried different clients alone. Some routers will only allow one VPN client (IPSec client)  at a time.
lowfellAuthor Commented:
The networks are different.

I can make a connection if i use another dialup or adsl. the problem only seems to be with the dsl connection here at work.

The adsl line seems to work fine and the only issue here is when users
 go through the company dsl  & then  start the SecureClient and try to get to the lan

If the come through another dsl or dialup. then use the secureclient, they can get to the lan?
Rob WilliamsCommented:
Another possibility is the DSL modem you are using is a combined modem and router. If that is the case the router's public interface (WAN connection) would have a private IP (192.168.x.x, 10.x.x.x, or 172.16-31.x.x) rather than a true public IP. This would indicate that both the modem and the router (2 devices) are performing NAT (Network Address Translation). VPN's don't like 2 NAT devices. However if this were the case I doubt the one user would be able to connect.
No chance that user has a laptop with wireless, and it is actually connecting through another Internet connection ?
What Security Threats Are We Predicting for 2018?

Cryptocurrency, IoT botnets, MFA, and more! Hackers are already planning their next big attacks for 2018. Learn what you might face, and how to defend against it with our 2018 security predictions.

lowfellAuthor Commented:
Right, these users all have their own adsl provided by the same isp. They then use their secureremote client to make a vpn connection to the checkpoint firewall.

They then all pass authentication, but are unable then to ping anything on the LAN??

However one user can ping stuff?
Rob WilliamsCommented:
>>"the only issue here is when users go through the company dsl  & then  start the SecureClient and try to get to the lan"
Are these users at site 'A' and trying to connect to a CheckPoint firewall at site 'A', the same site ? If so it shouldn't work at all.
lowfellAuthor Commented:
Right, this has been fixed by the enduser adding the wins/netbios servers to his local lmhosts file??

Beats me? Anyway this now works. He told me they couldn't ping anything?
He must have been trying to ping domain names & not ips?

Anyway, all seems good now.

Thanks for trying anyway Rob, as always much appreciated
Rob WilliamsCommented:
>>"He must have been trying to ping domain names & not ips"
Ah, that sounds right, especially if LMHosts fixed it. The one laptop that worked, probably had a slightly different DNS or NetBIOS over TCP/IP configuration allowing them to ping.
Thanks for the update and points.
Cheers !

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now