- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
09-08-2016 10:57 PM
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.
09-09-2016 01:08 AM
Hello,
Please could post an output of te command below:
> tail lines 100 mp-log ikemgr.log
09-09-2016 02:30 AM
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 <====
09-09-2016 03:15 AM
Hi,
Thanks for the logs. Is this VPN between Azure?
Thx,
Myky
09-09-2016 03:15 AM
Yes it is with Azure.
09-09-2016 03:20 AM - edited 09-09-2016 08:24 AM
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
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
09-09-2016 03:57 AM
We have Passive mode enabled , still getting same error.
09-12-2016 04:06 PM - edited 09-12-2016 04:08 PM
Hi,
l think these warning messages are normal.
But to be clear, open a TAC case.
Thx,
Myky
09-07-2020 11:58 PM
Did you end up finding it?
09-30-2020 05:40 AM
Hi have u got your answer vendor id payload ignored , why you were receiving that message
08-09-2021 10:38 AM
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.
08-11-2021 07:05 AM
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.
08-12-2021 05:18 AM
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!
01-03-2023 03:03 PM
This could be a authentication issue, please check the pre shared key once again.
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!