VPN issues after Portal certificate changed

[Howard_Gyton]

This morning I updated the firewall certificate, for Portal/VPN.

After I disconnected my Windows 11 Capsule VPN computer I could no longer connect.  We had this once before, and the fix was to delete the site, then re-create it.  The first time I did this that did not work.  So I deleted the site, then rebooted, then re-created it.  This time it worked, and I was asked an additional question about the site, and also now have additional options like "Network profile type" that were not there before.  I suspect because my computer was a Windows 10 to 11 upgrade, and the site existed on Win10.

For Endpoint users they receive a report that the certificate has changed, and should they trust the new one.  That seems to be okay.

But we have a lot of problem with SNX users, both on Mac, and a Win7 machine which I am currently looking at, where Capsule VPN is not an issue.

If I stop the SNX service from running, then from an elevated command prompt I run "slimsvc.exe debug" so I can see logs reported to the console, I see the following:

[ 9680 8572]@AZATHOTH[16 May 11:20:41][ssl_tunnel] ssl_link_fwasync_client_handler: state: << SSL_NEGOTIATION >> - negotiation ended and succeeded

[ 9680 8572]@AZATHOTH[16 May 11:20:41][ssl_tunnel] ssl_link_fwasync_client_handler: server_cn = portal.mrc-cbu.cam.ac.uk, server_fingerprint = BUT RACY JAR FISH BATE TOWN LIT LAND KATE ADD PAY DES

[ 9680 8572]@AZATHOTH[16 May 11:20:41][verify_CN] lookup_gw: Fingerprints match (BUT RACY JAR FISH BATE TOWN LIT LAND KATE ADD PAY DES)

[ 9680 8572]@AZATHOTH[16 May 11:20:41][ssl_tunnel] ssl_link_fwasync_client_handler: (termination code #303) Gateway was successfully verified by the user. Proceeding with connect...

[ 9680 8572]@AZATHOTH[16 May 11:20:41][ssl_tunnel] ssl_link_fwasync_client_handler: server_fingerprint_for_verification = BOGY INTO RAIL AIM FEET INN CAIN WHEE JAN GINA AMID VERB does not match gw_fingerprint = BUT RACY JAR FISH BATE TOWN LIT LAND KATE ADD PAY DES

At first it reports the the site is okay, and then says there is a cert. mismatch.  It looks like a local caching issue, but have not had much luck in resolving this so far.

As a workaround, years back CP provided us with a very old version of the SNX software which is command line enabled.  I can then use "snx -s <server> -u <user>" to connect, and this works.

I'm running through a few things with the Win7 user, including a complete uninstall of SNX, and related software, then reboot, with a view to re-install from scratch.

Has anyone come across this before?

Howard

[Howard_Gyton]

On the Win7 machine, after the uninstall, and reboot, then re-install of SNX we got a new pop-up:

However it still reports a fingerprint mismatch when viewing the output from "slimsvc.exe debug".

[the_rock]

Hm, thats interesting, as I never remember having to do that before, unless something changed in newer versions. Are you on R81.xx?

Andy

[Howard_Gyton]

R80.30

[the_rock]

I would confirm this with support, as I had to do this in my R81.10 lab recently and never had this sort of a problem. Usually, the only reason why you may need to re-create a vpn site if the IP changes, otherwise, I dont see why.

[Howard_Gyton]

Yes, we renew our certificates every year, and I don't remember having these issues, at least to this extent.  I have had the Capsule VPN error before, and back then it did require removing then re-creating the site.

I did what I did last time i.e. upload the new cert. to the firewall, then push policy.

It's never been an issue before.  I have opened a ticket with our support partner.

[the_rock]

You seem to know what you are doing, so I trust 100% you did it correctly. Plus, its super easy and straight forward process. I would definitely let TAC confirm all this.

[Howard_Gyton · Accepted solution]

Okay, that's weird.  I pushed policy a second time, but this time I ticked one additional box, which we usually never have turned on.

I managed to connect with my Windows 11 SNX install!  I'll be happy if I did something dumb here, but I don't remember having to tick that box before.

[the_rock]

Well, you only really need that box if you are using option for policy server, under ipsec vpn in gateway properties screen. I am pretty positive thats not really needed for MAB/snx.

[Howard_Gyton]

Yes, I haven't used that since the SecureClient days.  I'm waiting to hear back from the Win7 user to see if theirs has spontaneously started working.

[the_rock]

100% true! Let us know, because if that actually fixed it, yes, it would surprising, but it may help others it they ever encounter the same problem.

[Howard_Gyton]

I'm still awaiting feedback from others, including the Win7 user, but I am now seeing a few other SSL Network extender users connect, and from users I know I haven't provided the CLI enabled SNX to.

The only other user who has responded to my last email has reported that the "standard way works too", meaning the GUI.  But that may be because that user was one the SNX CLI users from this morning, and that it would work in both methods anyway.

But the logs themselves are looking promising.  If I hear anything more I will update ASAP.

That was quick!  I literally just had this come through:

"Works on Ubuntu now too (didn’t before).".

So perhaps that "Desktop Security" box does need to be ticked, at least for one push, if you change the VPN certificate?

And the Win7 user just got back to me:

"I tried again and now it works."

So I think that looks pretty certain in that case.

[the_rock]

It is good news indeed, and as I thought, if you have that option for policy server checked, which Im positive you do, you would see desktop policy option available in policy editor screen. Either way, not everything in this world makes sense, but if thats what fixes it, at least its an easy fix : - )

Andy

[Howard_Gyton]

I had another user reply to me today.  A Mac user who I was supposed to have a remote session with to look at this.  After I did the second policy push with the "Desktop Security" option ticked, this users login started working without me having to do anything.  They had already received a notification that the fingerprint had changed, and they had accepted that.  But they still couldn't connect.

Now they can.

I'm also working through some edge cases where Win10 Capsule VPN users still cannot connect.  The original advice was to remove the site, reboot, then re-create the site.  However for the last user an additional step was necessary.  After removing the site we then uninstalled Capsule VPN.  Once that was removed, we re-installed Capsule VPN, re-created the site, and the VPN worked.