Mailing List Archive

Hello,

I deployed the vpnc-0.5.3 client on a RHEL6 x86_64 host sucessfully. The
setup is an IPSEC Remote Access VPN implementation using hybrid mode of
authentication on the Cisco ASA 5505. I began to notice intermittent
disconnections with the error in the subject. The Cisco Tech. analyzed the
'debug crypto' logs from the ASA and he had this to say:

Has anyone seen this before ? Any guidance in this matter is highly
appreciated . I have attached the debug from the client

"
1) First deviation occurs at Phase 1.

-> After 3 Aggressive Mode messages are done & when ASA starts xauth,
Remote site should respond with xauth transactions. However it still sends
Agressive Mode Message 3 twice & therefore ASA logs 'duplicate Phase 1
packet received & dropping'.

Sep 05 13:44:23 [IKEv1]: Group = TESTVPN, IP = aa.aa.aa.aa, Duplicate Phase
1 packet detected. Retransmitting last packet.
Sep 05 13:44:23 [IKEv1]: Group = TESTVPN, IP = aa.aa.aa.aa, P1 Retransmit
msg dispatched to AM FSM


So here we have check why Client is sending AM Message 3 multiple times. Is
it not receiving the AM Mode Message 2 which is sent by ASA or is it not
able to process AM Message 2 from ASA for some time?
2)

Payload Notification
Next Payload: None
Reserved: 00
Payload Length: 12
DOI: IPsec
Protocol-ID: PROTO_ISAKMP
Spi Size: 0
Notify Type: PAYLOAD_MALFORMED
Sep 05 13:44:23 [IKEv1]: IP = aa.aa.aa.aa, IKE_DECODE RECEIVED Message
(msgid=1f8a5989) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0)
total length : 64
Sep 05 13:44:23 [IKEv1 DEBUG]: Group = TESTVPN, Username = USERNAME, IP =
aa.aa.aa.aa, processing hash payload
Sep 05 13:44:23 [IKEv1 DEBUG]: Group = TESTVPN, Username = USERNAME, IP =
aa.aa.aa.aa, processing notify payload
Sep 05 13:44:23 [IKEv1]: Group = TESTVPN, Username = USERNAME, IP =
aa.aa.aa.aa, Received non-routine Notify message: Payload malformed (16)

This indicates that:
* At some point during IKE negotiation, client is sending us duplicate
packets indicating that previous packets sent from ASA are either not
reached client completely
or in entirity or client was not able to process it.
At this point it appears that though Cisco ASA is responding correctly to
the negotiations, client is showing 'out of ordinary' behavior.

- Ajay