Все указывает на то, что винде не нравится сертификат
проблемы могут быть в свойствах сертификата (шаблон, назначение, параметры ключа и т.д.), в списке альтернативных имен, в субъекте сертификата и т.д.
вот что пишет журнал «Здоровье» по этой ошибке — что из этого проверяли/пробовали?
Error 13801: the IKE authentication credentials are invalid
You encounter this issue when either the server or client can’t accept the IKE authentication credentials.Error 13801 cause
This error can occur due to the following:— The machine certificate used for IKEv2 validation on the RAS server doesn’t have Server Authentication enabled under Enhanced Key Usage.
— The machine certificate on the RAS server expired.
— The client machine doesn’t have the root certificate for validating the RAS server certificate.
— The client machine’s VPN server name doesn’t match the subjectName value on the server certificate.Solution 1: verify the server certificate settings
If the issue is the RAS server machine certificate, make sure the certificate includes Server Authentication under Enhanced Key Usage.Solution 2: make sure the machine certificate is still valid
If the issue is that the RAS machine certificate expired, make sure it’s still valid. If it isn’t, install a valid certificate.Solution 3: make sure the client machine has a root certificate
If the issue is related to the client machine not having a root certificate, first check the Trusted Root Certification Authorities on the RRAS server to make sure the certification authority you’re using is there. If it isn’t there, install a valid root certificate.Solution 4: make the client machine’s VPN server name matches the server certificate
First, make sure the VPN client connects by using the same fully qualified domain name (FQDN) that the VPN server certificate uses. If not, change the client name to match the server certificate name.
Certificate configuration is crucial for Always On VPN deployments. I described some specific certificates requirements for IKEv2 in this previous post. Following this guidance, administrators should have no issues with IKEv2 Always On VPN connections. However, it is always possible to encounter an error if any of these certificates are missing or misconfigured.
Error 13801
One of the most common errors related to IKEv2 and certificates is 13801. When an Always On VPN connection using IKEv2 fails, the Windows Application event log will record an event ID 20227 from the RasClient source. The error message states the following:
“The user [username] dialed a connection named [connection name] which has failed. The error code returned on failure is 13801”.
IKE Authentication Credentials are Unacceptable
Error 13801 translates to ERROR_IPSEC_IKE_AUTH_FAIL, indicating an authentication failure related to IPsec. The problem can be on the device, the VPN server, or an issue with the VPN server configuration.
Authentication Methods
To begin, ensure that the appropriate authentication method is enabled on the Routing and Remote Access (RRAS) server. Right-click the VPN server in the RRAS management console (rrasmgmt.msc) and choose Properties. Next, click on the Security tab and then click on the Authentication Methods button.
Select the ‘Extensible authentication protocol (EAP)’ to support IKEv2 user tunnel connections. In addition, select ‘Allow machine certificate authentication for IKEv2’ to support Always On VPN device tunnel connections.
Certificate Chain
A 13801 error will occur if the client does not trust the certificate installed on the VPN server. Ensure the client has all the necessary root and intermediate certification authority (CA) certificates installed in their respective certificate stores.
VPN Server Certificate
A 13801 error can also occur if the VPN server does not have a properly configured server certificate. Ensure the VPN server has a valid certificate issued by the organization’s internal PKI that includes both the Server Authentication (OID 1.3.6.1.5.5.7.3.1) and IP security IKE intermediate (OID 1.3.6.1.5.5.8.2.2) EKUs. The subject name must match the public fully qualified domain name (FQDN) used by VPN clients to connect to the VPN server (not the server’s NetBIOS name). Again, ensure the certificate is valid (not expired), trusted, not revoked, and all necessary root and intermediate CA certificates are installed in their respective certificate stores.
Certificate Revocation
An expired Certificate Revocation List (CRL) can also result in a 13801 error. Open the Enterprise PKI console (pkiview.msc) on an issuing CA and review the status of all CRLs. If any are expired, resolve any issues preventing the CRL from publishing successfully, then issue a new CRL by running certutil.exe -crl on the issuing CA server.
RRAS Configuration
Another cause of the 13801 error for the device tunnel is a misconfigured Routing and Remote Access Service (RRAS) VPN server. An error 13801 can happen if the administrator incorrectly defines a trusted root CA using Set-VpnAuthProtocol. Ensure that the root certificate thumbprint matches exactly the root CA server’s thumbprint used to issue certificates to VPN devices and the VPN server.
Get-VpnAuthProtocol
Root CA Certificate Thumbprint
Resolution
Ensure that devices and VPN servers have correctly configured certificates installed. If the root CA certificate is assigned incorrectly on the VPN server, follow the guidelines detailed here to update the configuration.
Additional Information
Microsoft Windows Always On VPN Error 13806
Microsoft Windows Always On VPN Certificate Requirements for IKEv2
Microsoft Windows Always On VPN IPsec Root Certificate Configuration Issue
Microsoft Windows Always On VPN IKEv2 Policy Mismatch Error
Microsoft Windows Always On VPN IKEv2 Security Configuration
Microsoft Windows Always On VPN IKEv2 Fragmentation
Microsoft Windows Always On VPN IKEv2 Load Balancing and NAT
Microsoft Windows Always On VPN IKEv2 Features and Limitations
Windows 7 client can’t connect to strongswan 5.5.0, windows error 13801
Category:
interoperability
Resolution:
No change required
Description
Hi,
I followed offical Wiki page: https://wiki.strongswan.org/projects/1/wiki/Windows7 to setup the windows 7 client and the strongswan gateway, but fail to setup tunnel, windows report error 13801; and checked the strongswan certificate, it seems to match all certificate requirements:
root@HOMESVR:/usr/local/etc/ipsec.d/certs# openssl x509 -in homegw.hujun.tk.cert -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
62:e4:f7:66:d6:c1:ec:64:9b:4e:68:10:e0:59:1e:93
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=IL, O=StartCom Ltd., OU=StartCom Certification Authority, CN=StartCom Class 1 DV Server CA
Validity
Not Before: Oct 17 09:27:32 2016 GMT
Not After : Oct 17 09:27:32 2019 GMT
Subject: C=US, CN=homegw.hujun.tk
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus: (omitted)
Exponent: (omitted)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
52:78:66:34:89:B6:B2:1D:D2:09:7A:F2:C8:A8:9B:96:B0:CD:63:95
X509v3 Authority Key Identifier:
keyid:D7:91:4E:01:C4:B0:BF:F8:C8:67:93:44:9C:E7:33:FA:AD:93:0C:AF
Authority Information Access:
OCSP - URI:http://ocsp.startssl.com
CA Issuers - URI:http://aia.startssl.com/certs/sca.server1.crt
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.startssl.com/sca-server1.crl
X509v3 Subject Alternative Name:
DNS:homegw.hujun.tk
X509v3 Issuer Alternative Name:
URI:http://www.startssl.com/
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.23223.1.2.5
CPS: https://www.startssl.com/policy
and if I open the strongswan certificate on the windows client, it checks ok, see the attached screen shoot;
following is the strongswan config and log:
config setup
conn %default
keyexchange=ikev2
ike=aes256-sha256-modp1024
esp=aes256-sha256
dpdaction=clear
dpddelay=300s
conn rw
left=%any
leftsubnet=0.0.0.0/0
leftfirewall=yes
leftid=@homegw.hujun.tk
leftauth=pubkey
leftcert=homegw.hujun.tk.cert
leftsendcert=always
right=%any
rightsourceip=192.168.10.0/25
auto=add
rightauth=eap-mschapv2
eap_identity=%any
log:
Dec 8 19:41:36 07[NET] received packet: from 192.168.1.254[500] to 192.168.1.1[500] (792 bytes) Dec 8 19:41:36 07[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] Dec 8 19:41:36 07[IKE] 192.168.1.254 is initiating an IKE_SA Dec 8 19:41:36 07[LIB] size of DH secret exponent: 1023 bits Dec 8 19:41:36 07[IKE] local host is behind NAT, sending keep alives Dec 8 19:41:36 07[IKE] remote host is behind NAT Dec 8 19:41:36 07[IKE] sending cert request for "C=US, ST=CA, CN=HJ_ROOT_CA" Dec 8 19:41:36 07[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ] Dec 8 19:41:36 07[NET] sending packet: from 192.168.1.1[500] to 192.168.1.254[500] (337 bytes) Dec 8 19:41:36 05[NET] received packet: from 192.168.1.254[4500] to 192.168.1.1[4500] (1568 bytes) Dec 8 19:41:36 05[ENC] parsed IKE_AUTH request 1 [ IDi CERTREQ N(MOBIKE_SUP) CPRQ(ADDR DNS NBNS SRV) SA TSi TSr ] Dec 8 19:41:36 05[IKE] received 62 cert requests for an unknown ca Dec 8 19:41:36 05[CFG] looking for peer configs matching 192.168.1.1[%any]...192.168.1.254[192.168.1.139] Dec 8 19:41:36 05[CFG] selected peer config 'rw' Dec 8 19:41:36 05[IKE] EAP-Identity request configured, but not supported Dec 8 19:41:36 05[IKE] initiating EAP_MSCHAPV2 method (id 0x36) Dec 8 19:41:36 05[IKE] peer supports MOBIKE Dec 8 19:41:36 05[IKE] authentication of 'homegw.hujun.tk' (myself) with RSA signature successful Dec 8 19:41:36 05[IKE] sending end entity cert "C=US, CN=homegw.hujun.tk" Dec 8 19:41:36 05[ENC] generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/MSCHAPV2 ] Dec 8 19:41:36 05[NET] sending packet: from 192.168.1.1[4500] to 192.168.1.254[4500] (2176 bytes) Dec 8 19:41:57 16[IKE] sending keep alive to 192.168.1.254[4500] Dec 8 19:42:06 05[JOB] deleting half open IKE_SA after timeout
and I do use homegw.hujun.tk (not ip address) in window client configuration
History
#1
Updated by Jun Hu over 8 years ago
I changed the strongswan certificate to a lets encrypt issued cert, same problem
(sorry for the mess of original post, I can’t find way to edit it)
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:fd:12:81:02:21:6c:e3:78:4f:fa:b8:fb:31:43:50:98:4e
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Validity
Not Before: Dec 9 03:52:00 2016 GMT
Not After : Mar 9 03:52:00 2017 GMT
Subject: CN=homegw.hujun.tk
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:(omitted)
Exponent: (omitted)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
B0:8F:81:6C:65:CA:CD:0B:75:E3:0E:35:2D:B4:F2:F1:9C:B9:F0:54
X509v3 Authority Key Identifier:
keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
Authority Information Access:
OCSP - URI:http://ocsp.int-x3.letsencrypt.org/
CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
X509v3 Subject Alternative Name:
DNS:homegw.hujun.tk
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.44947.1.1.1
CPS: http://cps.letsencrypt.org
User Notice:
Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/
#2
Updated by Tobias Brunner over 8 years ago
- Description updated (diff)
- Status changed from New to Feedback
Dec 8 19:41:36 05[IKE] EAP-Identity request configured, but not supported
Make sure you have the eap-identity plugin loaded.
#3
Updated by Jun Hu over 8 years ago
Tobias Brunner wrote:
[…]
Make sure you have the eap-identity plugin loaded.
I recompiled strongswan (now using 5.5.1) to include eap-identitiy , still same problem…
is there any way to see some useful debug on windows 7 ? I tried enabled logging for the windows dialer, but the log file doesn’t provide any useful information that helps trouble shoot this issue
Dec 9 10:43:33 06[NET] received packet: from 146.74.94.66[166] to 192.168.1.1[500] (792 bytes) Dec 9 10:43:33 06[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] Dec 9 10:43:33 06[IKE] 146.74.94.66 is initiating an IKE_SA Dec 9 10:43:33 06[LIB] size of DH secret exponent: 1015 bits Dec 9 10:43:33 06[IKE] local host is behind NAT, sending keep alives Dec 9 10:43:33 06[IKE] remote host is behind NAT Dec 9 10:43:33 06[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ] Dec 9 10:43:33 06[NET] sending packet: from 192.168.1.1[500] to 146.74.94.66[166] (312 bytes) Dec 9 10:43:33 08[NET] received packet: from 146.74.94.66[26235] to 192.168.1.1[4500] (1564 bytes) Dec 9 10:43:33 08[ENC] parsed IKE_AUTH request 1 [ IDi CERTREQ N(MOBIKE_SUP) CPRQ(ADDR DNS NBNS SRV) SA TSi TSr ] Dec 9 10:43:33 08[IKE] received 62 cert requests for an unknown ca Dec 9 10:43:33 08[CFG] looking for peer configs matching 192.168.1.1[%any]...146.74.94.66[10.21.130.12] Dec 9 10:43:33 08[CFG] selected peer config 'rw' Dec 9 10:43:33 08[IKE] initiating EAP_IDENTITY method (id 0x00) Dec 9 10:43:33 08[IKE] peer supports MOBIKE Dec 9 10:43:33 08[IKE] authentication of 'homegw.hujun.tk' (myself) with RSA signature successful Dec 9 10:43:33 08[IKE] sending end entity cert "CN=homegw.hujun.tk" Dec 9 10:43:33 08[ENC] generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ] Dec 9 10:43:33 08[NET] sending packet: from 192.168.1.1[4500] to 146.74.94.66[26235] (1660 bytes) Dec 9 10:43:53 10[IKE] sending keep alive to 146.74.94.66[26235] Dec 9 10:44:03 06[JOB] deleting half open IKE_SA after timeout
#4
Updated by Jun Hu over 8 years ago
OK, I found the cause; the problem is fixed after I added the intermediate CA certificate in ipsec.d/cacerts/ and strongswan send both EE cert and intermediate CA certs to windows 7, now windows 7 happily accepts them and tunnel is created successfully;
this is a really weird issue, since windows 7 client DOES have the intermediate CA cert in its store, why it expect client to send full chain?
anyway I suggest the this should be added to the strongswan windows 7 wiki page that windows 7 actually expect to receive full cert chain from client;
Dec 9 11:09:30 09[NET] received packet: from 146.74.94.66[500] to 192.168.1.1[500] (792 bytes)
Dec 9 11:09:30 09[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
Dec 9 11:09:30 09[IKE] 146.74.94.66 is initiating an IKE_SA
Dec 9 11:09:30 09[LIB] size of DH secret exponent: 1023 bits
Dec 9 11:09:30 09[IKE] local host is behind NAT, sending keep alives
Dec 9 11:09:30 09[IKE] remote host is behind NAT
Dec 9 11:09:30 09[IKE] sending cert request for "C=US, ST=CA, CN=HJ_ROOT_CA"
Dec 9 11:09:30 09[IKE] sending cert request for "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"
Dec 9 11:09:30 09[IKE] sending cert request for "C=IL, O=StartCom Ltd., OU=StartCom Certification Authority, CN=StartCom Class 1 DV Server CA"
Dec 9 11:09:30 09[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
Dec 9 11:09:30 09[NET] sending packet: from 192.168.1.1[500] to 146.74.94.66[500] (377 bytes)
Dec 9 11:09:30 08[NET] received packet: from 146.74.94.66[4500] to 192.168.1.1[4500] (1568 bytes)
Dec 9 11:09:30 08[ENC] parsed IKE_AUTH request 1 [ IDi CERTREQ N(MOBIKE_SUP) CPRQ(ADDR DNS NBNS SRV) SA TSi TSr ]
Dec 9 11:09:30 08[IKE] received 62 cert requests for an unknown ca
Dec 9 11:09:30 08[CFG] looking for peer configs matching 192.168.1.1[%any]...146.74.94.66[10.21.130.12]
Dec 9 11:09:30 08[CFG] selected peer config 'rw'
Dec 9 11:09:30 08[IKE] initiating EAP_IDENTITY method (id 0x00)
Dec 9 11:09:30 08[IKE] peer supports MOBIKE
Dec 9 11:09:30 08[IKE] authentication of 'homegw.hujun.tk' (myself) with RSA signature successful
Dec 9 11:09:30 08[IKE] sending end entity cert "C=US, CN=homegw.hujun.tk"
Dec 9 11:09:30 08[IKE] sending issuer cert "C=IL, O=StartCom Ltd., OU=StartCom Certification Authority, CN=StartCom Class 1 DV Server CA"
Dec 9 11:09:30 08[ENC] generating IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
Dec 9 11:09:30 08[NET] sending packet: from 192.168.1.1[4500] to 146.74.94.66[4500] (3648 bytes)
Dec 9 11:09:30 06[NET] received packet: from 146.74.94.66[4500] to 192.168.1.1[4500] (80 bytes)
Dec 9 11:09:30 06[ENC] parsed IKE_AUTH request 2 [ EAP/RES/ID ]
Dec 9 11:09:30 06[IKE] received EAP identity 'hj'
Dec 9 11:09:30 06[IKE] initiating EAP_MSCHAPV2 method (id 0xEA)
Dec 9 11:09:30 06[ENC] generating IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]
Dec 9 11:09:30 06[NET] sending packet: from 192.168.1.1[4500] to 146.74.94.66[4500] (112 bytes)
Dec 9 11:09:30 10[NET] received packet: from 146.74.94.66[4500] to 192.168.1.1[4500] (144 bytes)
Dec 9 11:09:30 10[ENC] parsed IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ]
Dec 9 11:09:30 10[ENC] generating IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ]
Dec 9 11:09:30 10[NET] sending packet: from 192.168.1.1[4500] to 146.74.94.66[4500] (144 bytes)
Dec 9 11:09:30 06[NET] received packet: from 146.74.94.66[4500] to 192.168.1.1[4500] (80 bytes)
Dec 9 11:09:30 06[ENC] parsed IKE_AUTH request 4 [ EAP/RES/MSCHAPV2 ]
Dec 9 11:09:30 06[IKE] EAP method EAP_MSCHAPV2 succeeded, MSK established
Dec 9 11:09:30 06[ENC] generating IKE_AUTH response 4 [ EAP/SUCC ]
Dec 9 11:09:30 06[NET] sending packet: from 192.168.1.1[4500] to 146.74.94.66[4500] (80 bytes)
Dec 9 11:09:30 16[NET] received packet: from 146.74.94.66[4500] to 192.168.1.1[4500] (112 bytes)
Dec 9 11:09:30 16[ENC] parsed IKE_AUTH request 5 [ AUTH ]
Dec 9 11:09:30 16[IKE] authentication of '10.21.130.12' with EAP successful
Dec 9 11:09:30 16[IKE] authentication of 'homegw.hujun.tk' (myself) with EAP
Dec 9 11:09:30 16[IKE] IKE_SA rw[2] established between 192.168.1.1[homegw.hujun.tk]...146.74.94.66[10.21.130.12]
Dec 9 11:09:30 16[IKE] scheduling reauthentication in 9908s
Dec 9 11:09:30 16[IKE] maximum IKE_SA lifetime 10448s
Dec 9 11:09:30 16[IKE] peer requested virtual IP %any
Dec 9 11:09:30 16[CFG] reassigning offline lease to 'hj'
Dec 9 11:09:30 16[IKE] assigning virtual IP 192.168.10.1 to peer 'hj'
Dec 9 11:09:30 16[IKE] CHILD_SA rw{2} established with SPIs c2fcf26a_i 23466624_o and TS 0.0.0.0/0 === 192.168.10.1/32
Dec 9 11:09:30 16[ENC] generating IKE_AUTH response 5 [ AUTH CPRP(ADDR DNS) SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_6_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) ]
Dec 9 11:09:30 16[NET] sending packet: from 192.168.1.1[4500] to 146.74.94.66[4500] (448 bytes)
#5
Updated by Tobias Brunner over 8 years ago
- Category set to interoperability
- Status changed from Feedback to Closed
- Assignee set to Tobias Brunner
- Resolution set to No change required
this is a really weird issue, since windows 7 client DOES have the intermediate CA cert in its store, why it expect client to send full chain?
Perhaps you didn’t put them in the right keystore or the correct folder there. But it’s also possible that this is really required, I guess Windows could be weird.
Also available in: Atom
PDF
One of the most common errors related to IKEv2 and certificates is 13801, IKE authentication credentials are unacceptable.
When an attempt VPN connection using IKEv2 fails, the Windows Application event log will record an event ID 20227 from the RasClient source. The error message states the following:
The user [username] dialed a connection named [connection name] which has failed. The error code returned on failure is 13801
Possible Cause
Possible causes of Error 13801:
- The machine certificate on the VPN server has expired
- The trusted root certificate to validate the VPN server certificate is absent on the client
- VPN server name as given on the client doesn’t match the subject name of the server certificate
- The machine certificate used for IKEv2 validation on VPN Server does not have Server Authentication as the EKU (Enhanced Key Usage).
Solution
Following solution will be applied for the cause trusted root certificate absent on the client PC.
1. Download following certificate
trusted-letsencrypt-ca.cer
2. Right-click on Start and select Run
3. Type in mmc and click on OK
4. If your PC User Account Control (UAC) enabled, on the User Account Control screen, click on Yes
5. Once the Microsoft Management Console (mmc) opens, click on File and select Add/Remove Snap-in
6. In the left menu, select Certificates and click on Add
7. On the next screen, click the radio button next to Computer account and click on Next
8. Click on Finish
9. Click on OK
10. In the Microsoft Management Console window, click on Certificates (Local Computer) to expand the list
From here onward, you will perform certificate import into 2 locations certificate stores:
- Trusted Root Certification Authorities
- Third-Party Root Certification Authorities
Trusted Root Certification Authorities
11. Expand Trusted Root Certification Authorities in the left pane, right-click on Certificates subfolder and select All Tasks and then Import
12. Click Next in the Certificate Import Wizard
13. Browse to where you saved the CA certificate downloaded earlier and select it. Then click on Open
14. Back to Certificate Import Wizard, click Next
15. In the Certificate Store window, ensure that it says Trusted Root Certification Authorities and click on Next
16. Click on Finish and then OK.
Third-Party Root Certification Authorities
17. Expand Third-Party Root Certification Authorities in the left pane, right-click on Certificates subfolder and select All Tasks and then Import
18. Click Next in the Certificate Import Wizard
19. Browse to where you saved the CA certificate downloaded earlier and select it. Then click on Open
20. Back to Certificate Import Wizard, click Next
21. In the Certificate Store window, ensure that it says Third-Party Root Certification Authorities and click on Next
22. Click on Finish and then OK.
Review
You should have by now successfully import root certificate ISRG Root X1 (Internet Security Research Group) into certificate store:
Trusted Root Certification Authorities
Third-Party Root Certification Authorities
You may close Microsoft Management Console (mmc) and click No
Now you may retry again reconnect your IKEv2 VPN.
==========================================================================================
If you face any difficulties on the setup, please feel free to contact our support team by submitting a ticket on https://247livesupport.biz or emailing out support team at [email protected].
Ошибки при подключении VPN
Главная задача любого сервиса VPN – создание защищенного соединения, которое помогает посещать заблокированные ресурсы. Подобное соединение называется VPN-тоннель, который связывает конкретного пользователя и удаленный сервер. Это достаточно сложная технология, требующая специальных знаний и оборудования.
Если программа сдает сбой – это ошибка подключения VPN, о которой немедленно сообщается пользователю. В данном сообщении, как правило, содержится код, указывающий на тип сбоя, что облегчает дальнейшую работу по его исправлению.
Максимально расширьте свои возможности в Интернете с помощью наших надежных серверов виртуальной частной сети! Всего от $4 в месяц вы сможете получить доступ к популярным международным сайтам, таким как Netflix, Amazon,Chatgpt, недоступные в РФ. Наши интуитивно понятные приложения и передовая технология шифрования обеспечат вам безопасный просмотр веб-страниц без ущерба для конфиденциальности. Кроме того, воспользуйтесь нашими демократичными ценами и бесплатным пробным периодом — присоединяйтесь прямо сейчас! Наши консультанты помогут вам выбрать наиболее подходящую систему защиты и настроить безопасные протоколы передачи данных – IKEv2, L2TP/ipsec, OpenVPN, Shadowsocks, WireGuard. Не упустите свой шанс — подключайтесь к нам, чтобы получить все эти преимущества по доступной цене уже сегодня!
Защитите свою информацию и свободно просматривайте веб-страницы с помощью нашего VPN-сервиса! Наше программное обеспечение совместимо с Android, Windows, Linux, MacOS, iOS, что гарантирует защиту вашей цифровой деятельности и личных данных от любых потенциальных рисков. Если вам нужна помощь в настройке системы, наши специалисты готовы оказать ее. Получайте потрясающие предложения на нашем TG-канале (https://t.me/rvpn_info) или подключайтесь к нашему телеграм-чату (https://t.me/rvpn_chat) для чтения новостей и оперативного решения любых проблем! Зарегистрируйтесь сейчас, чтобы защитить свои данные и получить мгновенный доступ к любым сайтам!
Поскольку большинство ошибок VPN типичны, при наличии определенной информации пользователь может самостоятельно исправить проблему. Важно отметить, что многие провайдеры самостоятельно вводят процедурные коды, исправляющие возникшие проблемы и неполадки. Но существует определенный перечень, требующий непосредственного вмешательства пользователя для конкретного решения проблемы.
Коды ошибок и пути решения проблемы
При сбое работе программного обеспечения VPN система выдает сообщение об этом, выдавая конкретный код ошибки. Каждый из выдаваемых кодов позволяет провести определенные процедуры, позволяющие с высокой долей вероятности решить проблемы.
Ошибка VPN 800
Описывает одну из наиболее распространенных проблем. Такой код выдается, когда программе не удалось установить удаленное соединение с сервером. Это указание на то, что запрос по какой-либо причине не достигает сервера. Такая ситуация может сложиться по нескольким причинам:
- Неправильно указанное имя или виртуальный адрес сервера.
- Установка сетевых брандмауэров, некоторые из них просто блокируют VPN-траффик.
- Потеря связи с локальной сетью.
- При использовании туннеля L2TP/IPSec неподходящий формат IPSec-переговоров в конфигурации параметров безопасности.
Такое случается, когда тоннель VPN имеет автоматические настройки, при этом не удается воссоздать соединение для всех образующихся туннелей.
Решение проблемы:
При подключении проверить все параметры, включая адрес сервера, логин и пароль.
Лучше не использовать брандмауэр или настроить его таким образом, чтобы разрешался транзит PPTP и/или VPN.
Ошибки VPN 609 и 633
При указании несуществующего типа устройства выдается ошибка 609, а в случае, когда соединение уже занято или неправильно используется, показывается ошибка 633. Это схожие проблемы, возникающие при неправильной настройке мини-портов или при использовании порта ТРС другими программами. Для подтверждения проблем с мини-портом, необходимо выявить его наличие, для этого в командной строке вводится команда netcfg.exe -q. Для разных тоннелей используются такие мини-порты:
- MS_PPTP для туннеля PPTP.
- MS_L2TP для туннеля L2TP.
- MS_AGILEVPN для туннеля переподключения VPN (IKEv2).
- MS_SSTP для туннеля SSTP.
Решение проблемы:
- Использовать встроенную диагностику Windows, если есть указание на отсутствие мини-порта. Утилит операционной системы может устранить возникшую проблему в автоматическом режиме.
- Установить и использовать диспетчер подключений мини-портов для доступа VPN.
- Перезагрузить компьютер или гаджет, после чего снова подключиться к VPN.
Ошибка VPN 0x80072746
Такой код выводится системой, когда уже работающее соединение удаленный хост закрывает в принудительном порядке. Причины проблемы – сертификат компьютера не привязывается к серверу VPN или такой сертификат просто не установлен на данном сервере.
Решение проблемы:
Выйти на связь с администраций компании, предоставляющей услуги VPN. Он даст информацию о факте установки сертификата компьютера на сервере ВПН.
При правильной установке сертификата выполнить привязку HTTPS нужно в командной строке сервера VPN ввести команду netsh http show ssl.
Ошибка VPN 809
Код 809 выдается системой в случае, если компьютеру не удалось установить соединение с ВПН сервером, который не отвечает на запросы.
Решение проблемы:
Подключить порт на маршрутизаторе или брандмауэре. Если не получается, можно развернуть туннель SSTP на сервере и на компьютере, через который и восстановить связь.
Ошибка VPN 13801
Это один из самых распространенных кодов ошибки, которая указывает на недопустимость учетных данных IKE. Она возникает в таких случаях:
Истечение срока действия сертификата на сервере RAS.
Сертификат проверки, применяемый на IKEv2 на сервере RAS, не имеет функции расширенного использования ключа «Аутентификация сервера» EKU.
Отсутствие на клиенте корневого сертификата, проверяющего сертификат RAS сервера.
На клиенте указано имя выбранного сервера VPN, не совпадающее с субъектом сертификата сервера.
Решение проблемы:
Решить вопрос можно только связавшись с администрацией провайдера ВПН.
Ошибка VPN 691
Выдача кода ошибки VPN 691 указывает на отказ в удаленном соединении. Причина – неопознанная комбинация представленного провайдеру логина и пароля или действующий протокол не поддерживается удаленным сервером.
Решение проблемы:
- Убедится, что введенные логин и пароль верны. Часто случается, что такая мелочь, как нажатый Caps Lock приводит в выдаче ошибки.
- Убедиться, что протокол, установленный у пользователя, поддерживается на сервере.
Ошибка VPN 0x800704C9
Данный код выдается в том случае, когда сервер не располагает доступным портом SSTP.
Решение проблемы:
Для устранения ошибки необходимо убедиться, что на RAS сервере достаточно настроенный для работы портов. Для этого нужно:
- Запустить Маршрутизация и удаленный доступ.
- Раскрыть сервер, выбрать Порты при помощи правой кнопки мыши и в контекстном меню выбрать Свойства.
- Найти мини-порт WAN (SSTP), щелкнуть по нему, затем нажать Настроить.
- В пункте Максимальное количество портов поставить желаемое число и нажать ОК. Число портов по умолчанию – 128.
- В окне Свойства порта тоже нажать ОК.
Ошибка VPN 789
Этот код выдается при неудачном подключении L2TP в связи с ошибкой при доступе к удаленному компьютеру.
Решение проблемы:
Нужно убедиться, что и на стороне пользователя и у провайдера используется правильные сертификат соединений L2TP/IPSec. То же нужно сделать и при использовании Pre Shared Key (PSK).
Иногда, кроме специфических шагов, решить проблему с ошибками VPN помогают общие рекомендации:
- Перезагрузить устройство и снова подключиться к провайдеру ВПН.
- Проверить работу антивирусных программ и, при необходимости, на время отключить их.
- Смените сервер ВПН. Тот, на который идет запрос может быть недоступен или перегружен.
- Сбитые настройки времени на устройстве могут привести к проблемам с подключением.
Как видим, нерешаемых проблем не существует, если ничего не помогает, можно обратиться в службу технической поддержки ВПН провайдера. Крайний метод – просто сменить ненадежного провайдера.