Connection to external AD broken after changing external gw IP

[sreingardt]

Hi guys,

I have a problem with my Security Gateway since I changed the external IP last Friday and all network configuration (default gw, routes, etc) were done. I tried to login with my certificate in Check Point Mobile for Windows client and it got stuck at 47%. The error message reads

OCSP: could not connect to server. Make sure the server is up and running.Email=(my e-mail),CN=(my CN in certificate)

We use a two-step login for VPN, first we check an external certificate with password and then we request the AD password for the user in the certificate.

The information on this error message is very sparse, so I have not been able to continue my search for a solution.

Has anyone had that message in the past or know how to search further?

Thank you.

Sascha

[_Val_]

I assume your GW has the object set up with the new IP address, and the policy pushed. 

It sounds like your VPN client is still trying to connect to the old GW IP address. Try setting up a new VPN site with the new IP address and see if you succeed

[sreingardt]

Hi _Val_,

yes we have changed the object und pushed the policy.

I have set up a new site after the configuration changes and the VPN client pulled the policy/profile from the site. If I forgot to change the client I would get Site not responding or else.

Regards Sascha

[_Val_]

So, if you define a new site, everything works?

[sreingardt]

Hi _Val_,

unfurtunately no. I have a new site for the new VPN gateway IP, but that was not the problem.

[_Val_]

I see. Please open a service ticket with TAC for this

[sreingardt]

Ok I will do that, thank you for your support.

[G_W_Albrecht]

Maybe sk178625 "Unreached OCSP" "OCSP: could not connect to server" reject and detect logs for traffic tha... ?

[sreingardt]

Hi,

we are not using URL Filtering or HTTPS inspection on the gateway.

The VPN connection worked all fine before we changed the interface IP. It would probably work if we clean-install the gateway, but I hope that the solution could be easier than that.

Regards Sascha

[PhoneBoy]

The client needs to be able to reach the management server in order to validate the VPN certificate.
This is done via CRL and/or OCSP.
Please double check the NAT configuration for your management object, which may need to be different to account for the new external IP of the gateway.
It's also possible you need to delete and re-add the site on your VPN client.

[sreingardt]

Hi PhoneBoy,

the VPN gateway connects directly to my external ldap server, so I use a NAT on the gateway. The rule is a very common static source NAT like VPN gateway object to ldap server port ldap - translated source: other source IP for VPN gateway.
But that NAT only affects the internal interface and not the external.

---

@PhoneBoy wrote:

It's also possible you need to delete and re-add the site on your VPN client.

---

What do you mean by that? If I change my NAT configuration do I have to delete the site or if I change the external IP?

Regards Sascha

[PhoneBoy]

Unless your management server has a public IP address, NAT is required for your clients to access it.
What is the precise NAT configuration on the management server object?
If it is tied to the external IP of your gateway, you may need to delete and re-add the site.

[sreingardt · Accepted solution]

Hi PhoneBoy,

I finally found the solution and would like to share my experience.

With vpn debug on ocsp=5 I found connection entries to an external ocsp provider ocsp.globalsign.com in the vpnd.elg  logfile and the gateway tried to connect to the destination via a proxy. This felt strange to me because I have a gateway that points to the internet but wanted to use an additional proxy. The proxy entry came from the Global Properties and was inherited by the gateway by default. Unfurtunately, the gateway was not in the proxy whitelist.

By that OCSP was not reachable and the vpn connection stuck. I set an override for the proxy configuration in the properties of the gateway and everything worked fine after that.

Thank you for your support.

Regards Sascha

[PhoneBoy]

Thanks for sharing the solution.
That would certainly cause an issue.