| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| CPUG group, We have 5 PC's that use Checkpoint SecureClient NGX R60 (Build 191) to connect to a Federal site. On two of those we re-installed Checkpoint after removing it to resolve a local network issue (was probably not necessary). On re-install neither of these PC's can make the initial connection to complete the Site Wizard. Our 3 other PC's all work fine from the same subnet on the same network (inside the same firewall). After doing some web research I downloaded the CPClean and used that to remove the software and reinstall - no change. I've been searching the CPUG site and have not found anything yet. Network and Firewall: I contacted the federal site and they say it must be the firewall at our location, our network techs say that if 3 PC's are connecting from inside our firewall then nothing is blocked on this side. What would be my best steps to T-shoot this issue, neither team on the networking side has supplied any guidance beyond finger pointing. Will appreciate any input. MB |
| |||
| Were the clients pre-installed on the PCs when you got them and now you can't setup the site again? Well, this doesn't answer your question as to WHY, but it should be a good workaround for the users in the meantime. Assuming same version of SecureClient installs, try this: Take 2 of the PCs, a working and non-working On the good PC, log in and stop the VPN client Dive into the install directory for the VPN client and grab the userc.C file With SecureClient stopped on the non-working PC, overwrite the userc.C file with the good one Start the VPN client and try to connect You will find that the site is now configured and you do not have to run the setup wizard to configure the site. During the test for connectivity, pay close attention to 'updating topology' during the login process. Note if updates fail and report back to us. If none of this is helpful, please provide more information on how the working clients were originally installed. __________________ There's no place like 127.0.0.1 |
| |||
| Thank you much. Iammbo's solution resolved the problem, once the site info was available the connection was established. In resolving this issue is there any particular place I should look to provide info to the network folks at either end? I mentioned that we had resolved the issue by loading the connection info from a working system (FYI: the firewall is not directly controlled by the local network group). They mentioned that in the past the Firewall external IP was changed and that caused a number of VPN's to fail since the source could not be authenticated by the destination VPN server (similar to a handshake before loading the site info). I would like to avoid this in the future and since it occurred on two PC's with fresh installs it does not seem to be an isolated incident. Will appreciate any feedback and thanks again for the excellent help, MB |
| |||
| if you can, use Visitor Mode during the site setup. I don't remember if it's called that, but it is the alernate method. It tunnels all of the connections across TCP 443 and may work. Ray |
| |||
| Quote:
Gateway/Cluster properties --> Remote Access --> Visitor Mode Configuration: 1) Support Visitor mode (checked) 2) Service to https NOTE: You MUST change the ssl port for Web GUI on gateways prior to this to another port that is not 443 I highly recommended Visitor mode due to it's ability to traverse locked down environments. __________________ There's no place like 127.0.0.1 |
![]() |
| Thread Tools | |
| Display Modes | |
| |