IPSec VPN Changed Cert Unexpectedly on USG H Series

Painted_Turtle

We were not able do the extensive testing necessary to confirm what was happening. So, we welcome confirmation, insight, or comments.

Under conditions unknown to us, toggling the “Enable” switch may cause the IPSec VPN to use a new certificate preventing users from being able to bring up a VPN connection.

The work-around that seemed to work, was to set the “Certificate for VPN Validation” to Manual and to select a particular certificate other than the default certificate.

On a prior day, we had previously created a VPN using the VPN-->IPSec VPN-->Remote Access VPN configuration. The “Certificate for VPN Validation” was set to “Auto.”

We had downloaded the “VPN Configuration Download for Native VPN Client”.

Today, we distributed it to a number of remote clients and set them up so that they could connect.

However, after a number of successes, for some unknown reason, we were having trouble with one of our clients. The others could bring up the VPN connection and get to internal resources. However, this one could not. We thought that perhaps we might have “fat fingered” the username or password. So we reentered the password, verified that the user was in the correct Group to be able to use the VPN, etc.

Wondering if maybe the VPN had to be restarted to load a new password, we tried toggling the “Enable” switch and when that did’t work, we even tried restarting the Flex H series device.

At some point in the process, we discovered that previously working clients were no longer able to bring up an IPSec tunnel.

At some point we looked in System-->Certificate-->My Certificate and noticed a number of “RemoteAccess-VPN-...” certificates. And in the “References” column, there was a “1” next to one of the certs having today’s date in the “Valid From” column. Checking the box to the left and clicking on the “Reference” option confirmed that it was used by the IKE service of RemoteAccess.

Since the IPSec VPN that we had downloaded and distributed the configuration had been previously created, this didn’t seem correct. One of the other f “RemoteAccess-VPN-...” certificates did have a date in “Valid From” column corresponding to the date we had initially created the configuration.

So, we went back to the VPN-->IPSec VPN-->Remote Access VPN. We changed the “Certificate for VPN Validation” from “auto” to “manual” and selecting the certificate with the right date. We then toggled the “Enable” switch off and on again, just to make sure that the setting had taken.

Now the previous users could again establish the IPSec VPN tunnels. And we were able to get the user that had previously been a problem to work as well.