ASA 5505 VPN, header invalid

Unanswered Question
Oct 13th, 2009

Hi All

Here are a few syslogs from my ASA that seem very suspicious:

4 Oct 13 2009 15:52:15 713903 IP =, Header invalid, missing SA payload! (next payload = 133)

4 Oct 13 2009 15:52:15 713903 IP =, Error: Unable to remove PeerTblEntry

3 Oct 13 2009 15:52:15 713902 IP =, Removing peer from peer table failed, no match!

3 Oct 13 2009 15:52:15 713048 IP =, Error processing payload: Payload ID: 1

I have no clue what the 38. ip address is -- I am not using this in my config anywhere. The ASA just has one site to site VPN and does not use this IP in any way anywhere in config.

What could be the root cause of these message? Is someone trying to exploit a vulnerability in the ASA ?

These messages are appearing every few minutes for the last 15 minutes. I don't think its possible for me to block the IP via ACL since VPN traffic processed first.

Please advise. Any insight on this issue greatly appreciated.


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
johnbroadway Wed, 10/14/2009 - 06:44

It may be an external address / site coming inbound (towards you).

Can you past further debug messages, making sure you've got the following enabled:

debug crypto isa sa

debug crypto ipsec sa


c0ldshadow Wed, 10/14/2009 - 15:31

Hi John,

Thanks for the tip, however the attack stopped so I am not seeing anything after running debug crypto isakmp and ipsec on the ASA

The IP address associated in the error was also used by a bot to create accounts on my web forum

Is there anything I can do to prevent these initial connections attempts from even being possible?

I only have 1 site to site VPN, and don't want anyone else to even be able hit port 500 udp for isakmp to start this out

Thanks for your help

johnbroadway Wed, 10/14/2009 - 23:45

You could create an inbound access-list on the outside interface of your ASA which only permits your remote sites external address to access the IKE & IPSec protocols.

One drawback of this approach however would be that you restrict your ability to have roaming IPSec users as you won't know their addresses.




This Discussion