Intermittent connectivity issues and dropped connections from HNV-enabled VMs to Azure resources over S2S VPN through NVGRE gateway

Applies to: Windows Server 2012 R2 DatacenterWindows Server 2012 R2 EssentialsWindows Server 2012 R2 Foundation More

Symptoms


When you have Hyper-V Network Virtualization (HNV)-enabled virtual machines that connect to Azure resources over Site-to-Site (S2S) VPN through a Network Virtualization using a Generic Routing Encapsulation (NVGRE) gateway, you encounter the following symptoms:
  • There are connectivity issues from HNV-enabled virtual machines to Azure resources over S2S VPN through the NVGRE gateway.
  • The VPN S2S tunnel from the NVGRE gateway remains connected, but no data passes through the connection.
The only way to regain connectivity is to disconnect and then reconnect the tunnel from the Azure portal, as doing this from the NVGRE gateway has no effect. After you perform a failover of the clustered NVGRE gateway virtual machine, the issue is reproduced almost exactly 60 minutes later.

Cause


This issue may occur for the following reasons:
  • A mismatch between settings for Perfect Forward Secrecy (PFS) causes the security association rekeying to fail for the IKEv2 connection.
  • The VMM default setting for PFS is PFS2048. However, the Azure VPN requirement is for PFS to be disabled.
The output taken on the VMM-side resembles the following:
EncryptionMethod = AES256
IntegrityCheckMethod = SHA1
CipherTransformConstants = AES256
AuthenticationTransformConstants = SHA196
PFSGroup = PFS2048
DHGroup = Group2
Protocol = IKEv2

Resolution


To resolve this issue, disable PFS in VMM to match the Azure VPN settings. To disable PFS on the VMM-side, follow these steps:
  1. Open the VPN advanced properties on the VMM VPN.
  2. Click VM network > Properties > VPN Connections, and then click the advanced tab.
  3. Set PFS to None.



For information about the requirements for VPN policies connecting to Azure, go to the following MSDN website:

More Information


If you encounter this issue, the IKE logging captured on the NVGRE gateway shows the following behavior during the rekey attempt: