VPN is failing on Phase-1 MM packet1

[Blason_R]

Hi Team,

I am trying to bring up this tunnel however when I debug on CP with ike and vpnd it shows this is failing on MM-Packet 1 and here are the logs for VPNd.elg. Third party IP is 143.244.xxx,xxx

[vpnd 30737 4081387456]@xxxxx[10 Dec 16:51:24][tunnel] Transmitter::Transmit: 152 bytes sent to 143.244.xxx.xxx port: 500 over UDP (IPv4).
[vpnd 30737 4081387456]@xxxxx[10 Dec 16:51:28][tunnel] Transmitter::TransmitRequest: Transmitting for: 0xb8f1978 over UDP (IPv4) (10). Next in 4000ms
[vpnd 30737 4081387456]@xxxxx[10 Dec 16:51:28][tunnel] UDPConnection::Send: Sent 148 bytes on connection 0xa5ab5e0
[vpnd 30737 4081387456]@xxxxx[10 Dec 16:51:28][tunnel] Transmitter::EndRequest: Done transmission for: 0xbac5188
[vpnd 30737 4081387456]@xxxxx[10 Dec 16:51:28][tunnel] Transmitter::EndRequest: Calling transmission handler, done for 0xbac5188
[vpnd 30737 4081387456]@xxxxx[10 Dec 16:51:28][tunnel] TransmissionDone: called (back) for: 0xbac5188
[vpnd 30737 4081387456]@xxxxx[10 Dec 16:51:28][tunnel] fwIsakmp_Timeout: TIMEOUT ABORT: phase1state: bacf608 phase2state 0
[vpnd 30737 4081387456]@xxxxx[10 Dec 16:51:28][tunnel] ReplyBy: entering for 0xbac5188
[vpnd 30737 4081387456]@xxxxx[10 Dec 16:51:28][tunnel] fillUserPeerByNegotiationCxt: entering: 0 0 0 0
[vpnd 30737 4081387456]@xxxxx[10 Dec 16:51:28][tunnel] fillUserPeerByNegotiationCxt: ERROR: phase2state is NULL, return
[vpnd 30737 4081387456]@xxxxx[10 Dec 16:51:28][tunnel] fwisakmp_new_sa_notify: notified.
[vpnd 30737 4081387456]@xxxxx[10 Dec 16:51:28][tunnel] fwisakmp_new_sa_notify: Got an error from isakmpd type 3 code 0
[vpnd 30737 4081387456]@xxxxx[10 Dec 16:51:28][tunnel] fwisakmp_got_error_from_isakmpd: kernel_instance: 1. Err type 3, err-code 0. Packetid: 2c9e680
[vpnd 30737 4081387456]@xxxxx[10 Dec 16:51:28] CFwdCommStreamLocal::Write called
[vpnd 30737 4081387456]@xxxxx[10 Dec 16:51:28] CFwdCommStreamLocal::Write sent 136 bytes

[Timothy_Hall]

If you are erroring out at packet 2 of IKEv1 Main Mode, there is a mismatch in the IKE Phase 1 settings between the two sides such as encryption algorithm, hashing algorithm, or DH group.  Packets 1-2 negotiate a common set of algorithms, packets 3-4 perform the DH key calculation (and determine if NAT-T is needed), and packets 5-6 perform the authentication usually with a pre-shared secret.

However it is not clear from your log whether the peer is actually responding at all (TIMEOUT ABORT), so you need to run a tcpdump looking for UDP/500 to conclusively determine if the peer is even responding with IKEv1 MM packet 2.  If not they probably don't have the correct setup or IP address for your firewall and are dropping your IKEv1 MM packet 1, or that traffic is being blocked by something else.

[the_rock]

I see the point @Timothy_Hall is making. Honestly, if its failing on MM packet 1, that is 100% something basic missing. If you ran command like this on CP -> tcpdump -nni any host x.x.x.x (external peer IP) and port 50...do you see anything? What is the other side?

[Blason_R · Accepted solution]

Thanks Team - Issue was resolved last night for me. It was due to mismatch in PSK.

Plus has to add NO NAT Rule on CP since the traffic was getting natted

And at other end I added peer as a responder since it was configured as a initiator as well.

[the_rock]

Good job! Its still bit odd to me that PSK was the issue, since that would always be packet 5 or 6 on MM.

[Timothy_Hall]

Yes normally an incorrect PSK will cause a failure at MM packets 5/6, but if the overall authentication type (PSK vs. Certificate) is set incorrectly that will cause a failure at MM packets 1/2 since they have to agree on the authentication type then, but the actual authentication itself is not performed until MM packets 5/6. 

That Phase 1 order of operations never made sense to me in the IKEv1 spec, as in let's do some complex negotiations with a peer, perform a computationally expensive DH key calculation, and THEN actually authenticate who we are talking to in the final part of Phase 1?  Really?