MM_WAIT_MSG6 & Header invalid, missing SA payload! (next payload = 4)

[zac ragoonath]

I came across this today while migrating a L2L / site to site tunnel from our ASA to a PaloAlto firewall (formerly Cisco ios device)

From my side I would see :

17  IKE Peer: x.x.x.x
    Type    : L2L             Role    : initiator 
    Rekey   : no              State   :  MM_WAIT_MSG6

Solution 1: This typically means the PSKs don't match, after we fixed that we saw this. Some Mfgrs do not process special characters the same.

Debugging shows:

%ASA-vpn-4-713903: IP = x.x.x.x, Header invalid, missing SA payload! (next payload = 4)

or 

Oct 01 10:33:43 [IKEv1]: IP =x.x.x.x Header invalid, missing SA payload! (next payload = 4)

The other side was able to see this:

"IKE phase-1 negotiation failed. When pre-shared key is used, peer-ID must be type IP address. Received type FQDN."

These errors mean that the ASA is sending it's DNS name entry for some reason.

Solution 2:  Configure "isakmp identity address"

ASA(config)# isakmp identity ?

configure mode commands/options:
  address      Use the IP address of the interface for the identity
  auto            Identity automatically determined by the connection type: IP address for preshared key and Cert DN for Cert based connections
                     hostname   Use the hostname of the router for the identity
  key-id         Use the specified key-id for the identity

Citation: http://www.cisco.com/c/en/us/td/docs/security/asa/asa84/configuration/guide/asa_84_cli_config/vpn_ike.html

D

  Determining an ID Method for IKEv1 and IKEv2 ISAKMP Peers

During ISAKMP Phase I negotiations, either IKEv1 or IKEv2, the peers must identify themselves to each other. You can choose the identification method from the following options:

Address	Uses the IP addresses of the hosts exchanging ISAKMP identity information.
Automatic	Determines ISAKMP negotiation by connection type: •IP address for preshared key. •Cert Distinguished Name for certificate authentication.
Hostname	Uses the fully qualified domain name of the hosts exchanging ISAKMP identity information (default). This name comprises the hostname and the domain name.
Key ID	Uses the string the remote peer uses to look up the preshared key.

The ASA uses the Phase I ID to send to the peer. This is true for all VPN scenarios except LAN-to-LAN IKEv1 connections in main mode that authenticate with preshared keys.

The default setting is auto.

To change the peer identification method, enter the following command:

crypto isakmp identity {address | hostname | key-id id-string | auto}

For example, the following command sets the peer identification method to hostname:

hostname(config)# crypto isakmp identity hostname

[jaf1985]

I had this error as well. Found when connecting to a PA that I had to issue the "isakmp identity address" command to get Phase 1 to complete.

https://supportforums.cisco.com/document/15196/how-use-isakmp-identity-address-command-configure-ipsec-vpn-tunnels-non-cisco-devices

Issue is the PA rejects a FQDN (which is what a PIX/ASA tries to send by default). Once applied the tunnel came up with no problem.

[JP Miranda Z]

Also from the ASA perspective, make sure you are using the IP of the peer on the tunnel-group configuration.

Hope this info helps!!

Rate if helps you!! 

-JP-

[Florin Barhala]

For anyone landing here I had the same error for a site-to-site between Cisco ASA 9.6.x and Palo Alto.

The ASA was behind a STATIC/bidirectional NAT, so it used a private IP on the outside interface.

Tunnel got fixed after two changes:

 - Enable NAT-T on the PaloAlto side so UDP/4500 was accepted 

 - Update Peer ID on the PaloAlto side with my private IP address used on the ASA, while the PeerAddress was the public IP used by the ASA.

[AurangzebK]

I hit the same issue last week. same scenario as Florin had.

Site A: FTD behind NAT device
SiteB: Palo Alto

SA state : MM_WAIT_MSG6 ( verified PSK, no issue there)

Did Debug on PA side, found peer identity wasn't matching because FTD was sending Private IP address where as PA was rejecting it.

Solution: On Palo Alto side made following changes

- Set the Peer identification to FTD Private IP.
- NAT-T was already enable in my case.

Regards