Unable to establish a connection on VPN Tunnel 2


I'm working with a partner who has a SonicWall firewall (NSA 6.5) and we're attempting to establish a Site-To-Site VPN between my AWS VPN and his SonicWall. We are able to get tunnel 1 up and active, but tunnel 2 throws the following error. Does anyone have a thought on what causes the following error we are seeing in CloudWatch?

Thanks for any suggestions, DB

{ "event_timestamp": 1669073636, "details": "AWS tunnel was unable to decrypt the security payload(s)", "dpd_enabled": true, "nat_t_detected": true, "ike_phase1_state": "established", "ike_phase2_state": "down" }

demandé il y a un an2927 vues
2 réponses

There are specific troubleshooting instructions in this Knowledge base article for VPN Phase2 issues:


Can you clarify if you are using Policy based VPN or Route based VPN, if route based is it Static route based or BGP?

Lastly, are you using IKEv1 or IKEv2?

If you are using IKEv2 you can change the Start-up action for the VPN, see this documentation

Startup action: The action to take when establishing the VPN tunnel for a new or modified VPN connection. By default, your customer gateway device initiates the IKE negotiation process to bring the tunnel up. You can specify that AWS must initiate the IKE negotiation process instead.

profile pictureAWS
répondu il y a un an
  • Hi Tushar, thanks for your reply. The tunnels are Route base, static and we are using IKEv2. We are using a Start-up option of 'Add', but I have tried 'Start' as well with no success. Tunnel 1 works fine for us, as we are only get the error I mentioned above on Tunnel 2. The AWS config for Tunnel 1 matches tunnel 2. Do you happen to know what the error "AWS tunnel was unable to decrypt the security payload(s)" means?

  • If the configs of tunnel1 and tunnel2 are matching exactly then I suggest to open a Support ticket with AWS and SonicWall.

  • Ok thanks. I'll go that route.


To activate both tunnels. The ipsec tunnel config should have overlapip=yes parameter set. By default, it is no. From ipsec spec,

a boolean (yes/no) that determines, when (left|right)subnet=vhost: is used, if the virtual IP claimed by this states created from this connection can with states created from other connections.
Note that connection instances created by the Opportunistic Encryption or PKIX (x.509) instantiation system are distinct internally. They will inherit this policy bit.
The default is no.
This feature is only available with kernel drivers that support SAs to overlapping conns. At present only the (klips) mast protocol stack supports this feature.
répondu il y a un an

Vous n'êtes pas connecté. Se connecter pour publier une réponse.

Une bonne réponse répond clairement à la question, contient des commentaires constructifs et encourage le développement professionnel de la personne qui pose la question.

Instructions pour répondre aux questions