Cisco ASA VPN question: %ASA-4-713903: IKE Receiver: Runt ISAKMP packet

Question

Dear community,
quite frequently I am now receiving the following error message in my ASA 5502's log:
Oct 17 12:52:17 <myASA> %ASA-4-713903: IKE Receiver: Runt ISAKMP packet discarded on Port 4500 from <some_ip>:<some_port>
Oct 17 12:52:22 <myASA> %ASA-4-713903: IKE Receiver: Runt ISAKMP packet discarded on Port 4500 from <some_ip>:<some_port>
Oct 17 12:52:27 <myASA> %ASA-4-713903: IKE Receiver: Runt ISAKMP packet discarded on Port 4500 from <some_ip>:<some_port>
The VPN Clients (in the last case: A linux vpnc) disconnect with message
   vpnc[7736]: connection terminated by dead peer detection
The ASA reports for that <some_ip> at around the same time:
Oct 17 12:52:32 <myASA> %ASA-4-113019: Group = blah, Username = johndoe, IP = <some_ip>, Session disconnected. Session Type: IPSecOverNatT, Duration: 2h:40m:35s, Bytes xmt: 2410431, Bytes rcv: 23386708, Reason: User Requested    
A google search did not reveal any explanation to the "%ASA-4-713903: IKE Receiver: Runt ISAKMP packet..." message -- so my questions would be
   1) What does the message exactly mean -- I know runts as a L2 problem so I d suppose it means the same: The ISAKMP packet is somehow
       crippled (I d suppose this happens during rekeying) ?
   2) Any idea where to look for the cause of this
          WAN related (however I d assume no -- why does this happen in these regular time frames as show above)?
          SW related (vpnc bug)?
Thanks in advance for any pointer...
Joachim

Answer 1

Yes.  You need to eliminate the things I've said to eliminate with the other side.  Ensure your configs are matching exactly.  They probably are, whatever, just make sure of it because it's easy.  You both need to run packet captures on your interfaces both in and out to even begin to have an idea of where to look.
The more info you can have just one person responsible for the better.  What I mean by that is, it's typically a nice step for the 'bigger end' to have the 'smaller end's' config file to look at.
If you are seeing packets come in your inside, leave your outside, and never make it to his inside, then take it a step at a time.
If you're seeing them come in his interface and never come back out, you know where to look.
Set your caps to a single host to single host if need be, and generate traffic accordingly.
You need to narrow down where NOT to look so that you know where TO look.  I would say then, and only then, do you get the ISP involved.  Once you're sure the problem exists between his edge device and your edge device.
I do exactly this for a living on a daily basis...day after day after day.  I'm responsible for over 200 IPSec s2s connections and thousands of SSL VPN sessions.  I always start the exact same way...from the very bottom.