Wireless Access

 Hi,

We have just renewed the IKE Server Certificate using an internal CA, but when we try to connect to VIA it does not work and the error code 7606 is shonw in the VIA log. The certificate was generated in our internal CA with RSA 1024bits, Server Authentication proposal and .pfx format. The client trusts on this CA.

We have tried the connection with an external users (which authenticates using a client certificate and an internal DB user) and with a corporative user (that authenticates using MSCHAPv2 with single sign on).  We suspect that maybe the problem cames from the IKE process.

These are the logs from the controller, so as you could  please help us. If you will need more information, please let me know it.

Thanks in advance,

hange_setup_p1: ID is IPv4
Aug 23 06:18:31 isakmpd[1561]: <103063> <DBUG> |ike| 83.58.111.242:4500-> exchange_setup_p1: USING exchange type ID_PROT
Aug 23 06:18:31 isakmpd[1561]: <103063> <DBUG> |ike| 83.58.111.242:4500-> New(2) ID_PROT Exchange ic 4fee410eb8103601 rc 70fa924d4412d082
Aug 23 06:18:31 isakmpd[1561]: <103063> <DBUG> |ike| 83.58.111.242:4500-> IKE Fragmentation
Aug 23 06:18:31 isakmpd[1561]: <103063> <DBUG> |ike| 83.58.111.242:4500-> arubaVIA_check_vendor_payload detected Aruba VIA
Aug 23 06:18:31 isakmpd[1561]: <103063> <DBUG> |ike| 83.58.111.242:4500-> IKE Fragmentation
Aug 23 06:18:31 isakmpd[1561]: <103063> <DBUG> |ike| 83.58.111.242:4500-> arubaVIA_check_VIAAuthProfile_vendor_payload: VIA Auth Profile : InternalDB_VIAAuthenticationProfile
Aug 23 06:18:31 isakmpd[1561]: <103063> <DBUG> |ike| 83.58.111.242:4500-> message_recv enabling early NATT since peer initiates on 4500
Aug 23 06:18:31 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> ike_phase_1.c:ike_phase_1_responder_recv_SA:850 Recvd VPN IKE Phase 1 SA transform negotiation (1st packet) from IP 83.58.111.242.
Aug 23 06:18:31 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> ike_phase_1.c:attribute_unacceptable:2708 Proposal match failed in auth algo, configured=PRE_SHARED, peer using=IKE_AUTH_XAUTHINIT_RSA_SIG
Aug 23 06:18:31 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> ike_phase_1.c:attribute_unacceptable:2737 Proposal match failed in key length, configured=32, peer using=16
Aug 23 06:18:31 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> ike_phase_1.c:attribute_unacceptable:2708 Proposal match failed in auth algo, configured=PRE_SHARED, peer using=IKE_AUTH_XAUTHINIT_RSA_SIG
Aug 23 06:18:31 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> ike_phase_1.c:attribute_unacceptable:2737 Proposal match failed in key length, configured=32, peer using=16
Aug 23 06:18:31 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> ike_phase_1.c:attribute_unacceptable:2708 Proposal match failed in auth algo, configured=PRE_SHARED, peer using=IKE_AUTH_XAUTHINIT_RSA_SIG
Aug 23 06:18:31 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> ike_phase_1.c:attribute_unacceptable:2737 Proposal match failed in key length, configured=32, peer using=24
Aug 23 06:18:31 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> ike_phase_1.c:attribute_unacceptable:2708 Proposal match failed in auth algo, configured=PRE_SHARED, peer using=IKE_AUTH_XAUTHINIT_RSA_SIG
Aug 23 06:18:31 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> ike_phase_1.c:attribute_unacceptable:2737 Proposal match failed in key length, configured=32, peer using=24
Aug 23 06:18:31 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> ike_phase_1.c:attribute_unacceptable:2708 Proposal match failed in auth algo, configured=PRE_SHARED, peer using=IKE_AUTH_XAUTHINIT_RSA_SIG
Aug 23 06:18:31 isakmpd[1561]: <103063> <DBUG> |ike| 83.58.111.242:4500-> group_get entered id:2
Aug 23 06:18:31 isakmpd[1561]: <103063> <DBUG> |ike| 83.58.111.242:4500-> group_get ike_group:0x10000178
Aug 23 06:18:31 isakmpd[1561]: <103063> <DBUG> |ike| 83.58.111.242:4500-> modp_init entered
Aug 23 06:18:31 isakmpd[1561]: <103063> <DBUG> |ike| 83.58.111.242:4500-> group_get group:0x102cc284
Aug 23 06:18:31 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> ike_phase_1.c:ike_phase_1_responder_recv_SA:1000 Ike Phase 1 received SA
Aug 23 06:18:31 isakmpd[1561]: <103063> <DBUG> |ike| 83.58.111.242:4500-> ike_phase_1_responder_send_SA_NAT_T Accepted 1 of the Proposals, sending Response for exchange:83.58.111.242
Aug 23 06:18:31 isakmpd[1561]: <103063> <DBUG> |ike| 83.58.111.242:4500-> nat_t_exchange_check_nat_d_has_us src-port:500 dst-port:55530
Aug 23 06:18:31 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> nat_traversal.c:nat_t_generate_nat_d_hash:267 IP InnerIPController Port 500
Aug 23 06:18:31 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> nat_traversal.c:nat_t_exchange_check_nat_d_has_us:561 Did not find our matching NAT-D payload for Port:500 in their packet
Aug 23 06:18:31 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> nat_traversal.c:nat_t_generate_nat_d_hash:267 IP InnerIPController Port 4500
Aug 23 06:18:31 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> nat_traversal.c:nat_t_exchange_check_nat_d_has_us:571 Did not find our matching NAT-D payload for Port:4500 in their packet
Aug 23 06:18:31 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> ike_phase_1.c:ike_phase_1_recv_KE_NONCE:1254 Responder, enabling NAT-T.
Aug 23 06:18:32 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> nat_traversal.c:nat_t_generate_nat_d_hash:267 IP 83.58.111.242 Port 55530
Aug 23 06:18:32 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> nat_traversal.c:nat_t_generate_nat_d_hash:267 IP InnerIPController Port 4500
Aug 23 06:18:32 isakmpd[1561]: <103060> <DBUG> |ike| 83.58.111.242:4500-> nat_traversal.c:nat_t_exchange_add_nat_d:377 NAT-T added hashes for src=InnerIPController:4500, dst=83.58.111.242:4500
Aug 23 06:18:32 isakmpd[1561]: <103063> <DBUG> |ike| 83.58.111.242:4500-> ike_phase_1_send_KE_NONCE 83.58.111.242
Aug 23 06:18:32 isakmpd[1561]: <103063> <DBUG> |ike| ike_phase_1_post_exchange_KE_NONCE IV len:16
Aug 23 06:18:32 isakmpd[1561]: <103063> <DBUG> |ike| ike_phase_1_post_exchange_KE_NONCE done 83.58.111.242 g_x_len:128 skeyid_len:20

First, did VIA work before the certificate renewal/update?

The logs show a mismatch in IKEv1 phase 1.  "configured=PRE_SHARED, peer using=IKE_AUTH_XAUTHINIT_RSA_SIG"  Can you verify what the VIA Profile is configured to use:

Configuration --> Authentication --> L3 Authentication --> VIA Connection --> Your Profile --> Advanced --> 

What is set for VIA IKE Policy

Other considerations: 

Once you imported the new certificate to the controller, did you change the certificate which is used to for IKE communication for VPN clients?  

Configuration --> VPN Services --> IKE Server Certificate

If you setup a new VIA client, download the appropriate profile and try to connect; are you presented with any certificate messages upon initial connection?    What about from a machine that does not trust it?   I am trying to see if the proper certificate is being presented to the VIA client.

Lastly, you can try and grab the client side logs to see if they have any information.

Hi,

Thanks for your reply. I will answer to your questions:

• Yes, VIA worked fine before the certificate was renewed.  The older certifcate was generated with a diferent CA that the one that we have just renewed.  Maybe, it is something missing in the configuration? Any aditional action is needed in the new CA where we are generating the IKE Server Certificate?

We have two profiles:

1.  One for a corporative user which has the VIA IKE Policy configured with 20- AES256/SHA/PRE_SHARE/GROUP 2/ [300-86400] and IKEv2 enable. Authentication is based on windows credentials, which are valitaded against out internal radius server. 
2.  Another for an external user which has the VIA IKE Policy configured with 30- AES256/SHA/RSA/GROUP 2/ [300-86400] and IKEv2 disable. Client Authentication is based on certificates:  - The client has an authentication certificate.  - The controller needs to trust in the CA of the client certificate (CA Certificate Assigned for VPN-clients)  - The controller certificate is load and it is selected in the IKE Server Certificate field.  - The client in order to validate controller certificate has to trust on its CA.  - The client has also to trust in the CA of the WEBUI certificate.

•  When we change the IKE Server Certificate on the controller, VIA fails. We have generated several certificates in this way:   

1. We generated a CSR (rsa, key length 1024) in the controller and imported it on the  internal CA, just for generate the IKE Server Certificate.  
2. We generated a CSR (rsa, key length 2048) in the controller and imported it on the  internal CA, just for generate the IKE Server Certificate.  
3. We generated a CSR (rsa, key length 4096) in the controller and imported it on the  internal CA, just for generate the IKE Server Certificate.  
4. We create a new certificate directly on the CA for authentication server purpose for the controller (rsa, 1024) an dwe loaded it on the controller.

We have checked that the OCSP responder is disable.

The VIA client log (anacui) is attached. We observed that there are so many errors during the IKE process.

Thanks in advance,

- Are your client logs all set to DEBUG?

- Are both VIA profiles not working as a result of the change?

- When importing the new certificate to the controller, did you also import the Issuing CA as a TrustedCA on the Certificates page of the controller?

Hi,

I have set VIA logs to DEBUG level.It seems that this logs have more information than the others. In the anacui log there is a cetificate context error:

Aug 27 07:24:59.739  c34  ERROR anapp  1537  Gettign certtifacateContextProperty failed reason = 80090016

Have you ever seen this error before?

Both profiles (internal and external) dont work once we have changed the IKE server certificate.

We also have loaded the Issuing CA as trustedCA on the controller.  Is there anything else we have to load on the controller or in the client?

Thanks in advance,

Regards,

Did you create the new certificate with the same name (common name; CN) as the original?   I suggest you verify two things:

On the controller, make sure you have removed any old/expired certificates if they have the same name assigned.

On the client side, make sure there is not stored any old/expired certificates with this name in the trusted stores; root and/or intermediate.

On a client, download a copy of the controller certificate (public key only is fine).   Then verify the certificate with a tool like certutil.exe.  For example (on Windows):

certutil.exe -verify nameofcert.crt

Hi,

Thanks very much for your help. The problem was that the client have installed four CA certificates. Three of them were revoked and the fourth was ok. As soon as we delete the three old CA certificates installed on the client, VIA starts working. This old CA certificates are defined in Active Directory, so we should internally check it to correct the problem.

Thanks again,

Regards,

Hi,

I have a litte question about IKE server certificate generation. What is better, creating the certificate with a CSR on the controller or with pfx on a internal CA?

Thanks,

Neither is "better" than the other, but I sometimes like to do it offline with the pfx that way you have the private key available if you need it for another use.   However, depending on the security around the solution, having that private key can also be a security risk; in that case generating the CSR on the controller (or whatever device) is preferred.