pre-share vs rsa-sig

[drenaud]

Hello,

Can someone help me to check what kind of filtering can prevent to succesfully complete isakmp process using certificates as it works fine with preshared keys.

Both devices are cisco routers and synchronized on UTC and Certificates are OK.

The only difference is the isakmp priority.

Thanks a lot in advance

[ggilbert]

Hello,

Where does it fail?

deb cry isa

deb cry ipsec

Can you run those two debugs on both the routers and send the output from both the sides.

Thanks

gilbert

[drenaud]

Hello,

I attached some debug output from initiator and responder

Both ios config are attached too.

The only change between the outputs with certs and those with psk is the isakmp policy priority on the responder.

Thanks in advance for your help

[ggilbert]

Apr 11 08:10:47.184: ISAKMP:(0:6:HW:2):Old State = IKE_QM_I_QM1 New State =IKE_QM_PHASE2_COMPLETE

I see on both the sides that the Phase 2 is completed.

When you do " sh cry isa sa" do you see QM_IDLE for status of the tunnel.

When you do " sh cry ipsec sa" do you see the SA's created for the tunnel.

Cheers

Gilbert

[drenaud]

The Phase 2 complete succesfully when I use PSK authentication (the second part of resp_debug.txt and ini_debug.txt).

On the first part you can see output when I use RSA-SIG authentication, this one does not complete.

Responder seems to complete but initiator stop the Phase 1 process by a "purging node".

Regards

David

[aaronr]

My best guess...

The initiator sends its cert (signed by CA_group_doe)

Apr 11 07:25:17.799: ISAKMP:(0:5:HW:2):Send initial contact

Apr 11 07:25:17.803: ISAKMP:(0:5:HW:2):SA is doing RSA signature authentication using id type ID_FQDN

Apr 11 07:25:17.803: ISAKMP (0:268435461): ID payload

next-payload : 6

type : 2

FQDN name : vpn-customer.customer.intra

protocol : 17

port : 0

length : 27

Apr 11 07:25:17.807: ISAKMP:(0:5:HW:2):Total payload length: 27

Apr 11 07:25:17.815: ISAKMP (0:268435461): constructing CERT payload for serialNumber=49,cn=vpn-customer.customer.intra,ou=VPN Clients,o=group-doe,c=FR

Apr 11 07:25:17.815: ISKAMP: growing send buffer from 1024 to 3072

Apr 11 07:25:17.819: ISAKMP:(0:5:HW:2): using the CA_group_doe trustpoint's keypair to sign

Apr 11 07:25:17.851: ISAKMP:(0:5:HW:2): sending packet to 1.2.3.4 my_port 4500 peer_port 4500 (I) MM_KEY_EXCH

The responder likes this cert and authenticates the peer...then sends its cert back (signed by CA_group_doe) to the initiator. At this point it looks as though the initiator does not like the cert received and wants to go back to a key exchange, thus the MM_KEY_EXCH retransmits in the debugs.

So....what happens during the 5th and 6th messages of an RSA IKE P1 negotiation (messages 1 through 4 are the same regardless of PSK or RSA auth)? The 5th message should be the initiator sending authentication material and ID - i.e. its Signature, a Certificate payload, and an Identity payload (such as hostname or IP). The 6th message should be the responder sending roughly the same packet back to the initiator with the Signature, Cert payload, and ID payload fields updated.

So, based on that, it appears that the initiator does not like one of the three things above. The signature is invalid, the certificate payload is incorrect, or it does not like the identity listed of the peer.

I'm sure you've already done this, but I'll reiterate just in case...

1. Verify the CA cert is valid on both peers.

2. Verify that the OU and O fields of the peer certs are identical on both sides

3. Try removing the following, "crypto isakmp identity hostname" on both peers. This typically only helps when each side needs a distinguishing characteristic to determine what ISAKMP profile to match the peer to (at least in my understanding). Useful for PSKs, but I don't think you'll need it for RSA Sigs.

4. You might try changing the following, "rsakeypair group_rsa_key" under your trustpoint config to "rsakeypair group CA_group_doe" to reference what keychain to use. By default, I believe the router will use the FQDN certificate - which may be why the router is still functioning partly.

Hope this helps!

Aaron

[drenaud]

It helped me a lot but did not solved my problem.

The problem was solved by upgrading the gateway

router firmware (we use NAT-T). The problem is that this gateway is in charge of the provider.

Difficult to find someone helpfull like you everywhere. :-)

Thank you very much for your attention.

Bye