pre-shared-key vs cert authentication in DMVPN

[axfalk]

We have the following isakmp policy map on our ISR4331 router that we're using as a spoke:

Global IKE policy
Protection suite of priority 1
        encryption algorithm:   Three key triple DES
        hash algorithm:         Secure Hash Standard
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   ##2 (1024 bit
        lifetime:               86400 seconds, no volume limit
Protection suite of priority 10
        encryption algorithm:   AES - Advanced Encryption Standard (256 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #2 (1024 bit)
        lifetime:               86400 seconds, no volume limit 

Protection suite of priority 20
        encryption algorithm:   Three key triple DES
        hash algorithm:         Secure Hash Standard
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #2 (1024 bit)
        lifetime:               86400 seconds, no volume limit

So, based on the above, the pre-shared key authentication should be used as it's part of the Priority 1 Policy, which has the highest priority among the isakmp polices. However, we're seeing the cert as opposed to the pre-shared key is being used. 

Anybody happened to know the mechanism by which the authentication method is being chosen when the connection from the spoke to the HUB is being put together.

Thanks.

_ Greg

[Rob Ingram]

Hi,
When attempting to establish an IKE SA the spoke will send it's IKE/ISAKMP policies to the Hub, which will check it's configured policies (highest priority first) until a match is found. If you are matching on RSA rather than PSK, check the Hubs' IKE/ISAKMP policies are the same, also check the PSK on both the hub and spokes are defined and correct for each of the router.

If the configuration visibly looks ok, turn on debug and post the output here for review.

HTH

[axfalk]

Thanks for your response.

The ISAKMP policy on the spoke and the HUBs looks the same. However, there's only one HUB configured for the PSK on the spoke as opposed to the 2 HUBs. So, I would think the spoke would try establishing  an IKE SA with the HUB that it has PSK configured for matching on PSK, and then use RSA to establish an IKE SA with the HUB that the spoke doesn't have PSK configured for. Does this make sense?

Also, what is the definitive command to see what it's matching on, RSA or PSK?

Thanks again..

_ Greg

[Rob Ingram]

Yes that makes senses.

Use the command "show crypto isakmp sa" to determine authentication method and algorthims used. Post here if you want confirmation

HTH

[axfalk]

Global IKE policy
Protection suite of priority 1
        encryption algorithm:   Three key triple DES
        hash algorithm:         Secure Hash Standard
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   ##2 (1024 bit
        lifetime:               86400 seconds, no volume limit
Protection suite of priority 10
        encryption algorithm:   AES - Advanced Encryption Standard (256 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #2 (1024 bit)
        lifetime:               86400 seconds, no volume limit 

Protection suite of priority 20
        encryption algorithm:   Three key triple DES
        hash algorithm:         Secure Hash Standard
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #2 (1024 bit)
        lifetime:               86400 seconds, no volume limit

and it's the same policy on the spoke and the 2 HUBs....

so, from that command, does it look like it's matching on the PSK?

Thanks.

_ greg

[Rob Ingram]

If the rotuer doesn't have a PSK then it's not going to match against a PSK isakmp policy. Provide the output of “show crypto isakmp sa detail" that will confirm what it's matching against.

[axfalk]

Below is the ouput from the show crypto isakmp sa detail taken on the spoke for the 2 HUBs:

show crypto isakmp sa detail | i 65.240.195.10 (the HUB that has a PSK config on the spoke)
19919 99.137.20.225 65.240.195.10 ACTIVE 3des sha psk 2 08:44:00 D
show crypto isakmp sa detail | i 209.249.113.253 (the HUB that doesn't have a PSK config on the spoke) 
19920 99.137.20.225 209.249.113.253 ACTIVE aes sha rsig 2 08:43:25 D

It appears the spoke is matching on PSK for the HUB the spoke has a config for and it's matching on RSA for the HUB the spoke doesn't have a PSK config for....is this right?

So, it looks like it's working as designed?

Thanks.

_ Greg

[Rob Ingram]

Correct, yes it's matching policies #1 for PSK and #10 for RSA authentication.

Ideally you should look to define your own ISAKMP policies or migrate to IKEv2, as the algorithms within default policies are weak. Especially the policy #1 using 3DES.

HTH