Ike -generic event : vendor id payload ignored

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Ike -generic event : vendor id payload ignored

L4 Transporter

We are seeing continous  ike genric event for vendor id payload ignored , tunnel is up traffic getting encrypted and decrypted.

 

what exactly does above error say.

SD-WAN | Cloud Networking | PCNSE | ICSI CNSS | MCNA | | CCNP | CCSA | SPSP | SPSX | F5-101 |
15 REPLIES 15

L6 Presenter

Hello,

 

Please could post an output of te command below:

 

> tail lines 100 mp-log ikemgr.log

 

2016-09-08 10:05:30 [PROTO_NOTIFY]: ====> IKEv2 IKE SA NEGOTIATION STARTED AS RESPONDER, non-rekey <====
====> Initiated SA: X.X.X.X[500]-X.X.X.X[500] SPI:34a2990a7a92484b:efca7a95900a177b SN:15994 <====
2016-09-08 10:05:30 [PROTO_WARN]: 15994:x.x.x.x[500] - x.x.x.x[500]:0x9247c08:ignoring unauthenticated notify payload (NAT_DETECTION_SOURCE_IP)
2016-09-08 10:05:30 [PROTO_WARN]: 15994:x.x.x.x[500] - x.x.x.x[500]:0x9247c08:ignoring unauthenticated notify payload (NAT_DETECTION_DESTINATION_IP)
2016-09-08 10:05:30 [PROTO_WARN]: 15994:x.x.x.x[500] - x.x.x.x[500]:0x9247c08:vendor id payload ignored
2016-09-08 10:05:30 [PROTO_WARN]: 15994:x.x.x.x[500] - x.x.x.x[500]:0x9247c08:vendor id payload ignored
2016-09-08 10:05:30 [PROTO_WARN]: 15994:x.x.x.x[500] - x.x.x.x[500]:0x9247c08:vendor id payload ignored
2016-09-08 10:05:30 [PROTO_WARN]: 15994:x.x.x.x[500] - x.x.x.x[500]:0x9247c08:vendor id payload ignored
2016-09-08 10:05:30 [INFO]: 15994:x.x.x.x[500] - x.x.x.x[500]:0x916df28:authentication result: success
2016-09-08 10:05:30 [PROTO_NOTIFY]: ====> IKEv2 CHILD SA NEGOTIATION STARTED AS RESPONDER, non-rekey <====
====> Initiated SA: x.x.x.x[500]-x.x.x.x[500] message id:0x00000001 parent SN:15994 <====

SD-WAN | Cloud Networking | PCNSE | ICSI CNSS | MCNA | | CCNP | CCSA | SPSP | SPSX | F5-101 |

Hi,

 

Thanks for the logs. Is this VPN between Azure? 

 

Thx,

Myky

 

Yes it is with Azure.

SD-WAN | Cloud Networking | PCNSE | ICSI CNSS | MCNA | | CCNP | CCSA | SPSP | SPSX | F5-101 |

Hi,

 

What is your PAN-OS version?

We had a strange issue with this Azure s2s VPN. 

Please could you make sure you tick the box "passive mode" on IKE GATEWAY

 

passive.PNG

 

I could see it is a "responder" only but still we had similar behaviour. As soon as we ticked that box all went smoothly.

 

Thx,

Myky

We have Passive mode enabled , still getting same error.

SD-WAN | Cloud Networking | PCNSE | ICSI CNSS | MCNA | | CCNP | CCSA | SPSP | SPSX | F5-101 |

Hi,

 

l think these  warning messages are normal. 

 

 

Capture.PNG

 

But to be clear, open a TAC case.

 

Thx,

Myky

Did you end up finding it?

Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say.
-- Edward Snowden

@TranceforLife 

Hi have u got your answer vendor id payload ignored , why you were receiving that message 

L1 Bithead

We are having this issue with Azure VWAN S2S VPN gateway, specifically with instance 0 of the Azure VPN gateway (they run them in active/active pairing). Instance 1 has been working without issue. Rebooting our HA pair of 3050's, I can bring the VPN tunnel up, however that does not last and it will begin failing after a few hours. Weirdly, out of 4 sites we have with 3050's in HA pairing, only 2 of the sites are having issues with Azure VPN instance 0. PA software version 9.0.9 across all sites, managed with Panorama. Involving PA support now and I will report back if we find a resolution.

L1 Bithead

Sharing another update here. Microsoft support identified that the issue, currently, is that IKE traffic destined for Azure VPN gateway instance 0 is being received on instance 1. They insisted that the issue was with routing on our end, however they provided packet captures proving that the traffic had the destination public IP for instance 0, yet was being received by instance 1. We're leaning towards a Microsoft/Azure routing issue. More to come.

L1 Bithead

Last update, and the ultimate resolution on our end. We tore down and deleted the S2S VPN gateway on the Azure VWAN side, as well as removed the problematic tunnels from the PA side. Once it was re-deployed, the new VPN gateway instances had new public IPs, so I setup all 8 of our tunnels (4 sites, 2 tunnels per) using the new peering IPs and it has been stable since. I know anyone who's already running production traffic out to Azure will need a couple hour maintenance window to do this, so it may not be the answer you were looking for, but we luckily hadn't migrated production traffic over it yet.

 

Anyone who is facing this issue and may not have the time to do a complete re-deploy, I would urge you to have Azure/Microsoft run packet captures to see if there is a routing issue on the Azure side where packets for one instance are somehow arriving at the other instance. I never heard back from our engineer if he was able to find anything as we just proceeded with the re-deploy, but all signs were pointing to that. Hope this helps someone encountering issues with Azure VWAN!

L1 Bithead

Ope. I forgot to include the part that started this whole thread. Once this was fixed, I did see the 'vendor id payload ignored' error messages disappear from our ikemgr.log.

L0 Member

This could be a authentication issue, please check the pre shared key once again.

  • 34972 Views
  • 15 replies
  • 1 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!