Register-AzureRmProviderFeature -FeatureName AllowVnetPeering -ProviderNamespace Microsoft.Network –forceNow this “should” register you pretty quickly, but it took about an hour before I was able to actually setup a peer. The first step is to check and see if you are registered or registering by using the script below. If this says Registering then you have to wait. If it says Registered then you should be good to go. If you show as Registered and still get hours give it an hour then try again.
Get-AzureRmProviderFeature -FeatureName AllowVnetPeering -ProviderNamespace Microsoft.NetworkTo actually setup the peering you have to specify which vNets are allowed to talk to which other vNets. The easiest way to do this is in the Azure Portal (unless you have a bunch to do then use PowerShell). Log into the portal and navigate to your Virtual Networks. In the properties of the vNet you’ll see a new option called “Peerings”. Select this and click the “Add” button. Which will get you the new peering menu shown below. Give the peer a name (I used the name of the vNet that I was connecting to), specify if the peering is to an RM or Classic vNet (yes you read that correctly, Classic is supported, do a degree) the subscription and the vNet that you want to connect to. You can then enable and disable access to the vNet over the peer, and specify if the peer connection should allow forwarded traffic (from a site to site VPN for example) and if this peer should be allowed to use this vNets Gateway (if it has one). If the vNet you’re configuring doesn’t have a remote network gateway, you can check that bottom button to use the gateway of the remote vNet instead. Once that’s done click OK, then setup the same peering on the remove vNet. Give it a minute or two for the deployments to complete, then you should have full private IP communications between the two vNets. Now there’s a couple of restrictions to keep in mind.
- This only works across vNets in the same account.
- This only works across vNets in the same region, so vNets in different regions will still need to have a site to site VPN, but you only really need to have a single vNet in each region with a site to site VPN.
- Classic is supported, sort of. Classic vNets can ONLY peer to RM vNets, no Classic to Classic peering is supported.
Register-AzureRmResourceProvider -ProviderNamespace Microsoft.NetworkThe post Site to Site VPNs no longer needed for vNets in the same Azure region appeared first on SQL Server with Mr. Denny. Contact the Author | Contact DCAC