SOLVED

Best way to join VM from one VNet to Azure AD DS custom domain in a different VNet

Brass Contributor

Greetings.  I have a functioning Azure AD DS custom domain that is deployed to a subnet in let's say VNet1.  I have a VM that resides in a subnet of, call it VNet2, that I would like to join to the custom domain.  What's the simplest, most effective way to achieve this?  In looking thru the documentation, I've seen suggestions for Peering the two networks together.  This may be fine, but I may prefer to keep the networks separate for security reasons.  I have Azure VPN Gateways installed in both VNets so perhaps a site-to-site tunnel could be the best option?  Although, if I'm going to do that, then perhaps the Peering option would be the better way to go.  Would it be possible to just add a route table in the appropriate subnet of VNet2 and just let routing do the trick?  If so, how do I find out the next hop address to add to the route?  And would I associate it with the gateway subnet or the default subnet of VNet2?  Thanks in advance for any help.  I really want to understand what is regarded as a "best practice" in this scenario.

 

Thanks again and cheers,

 

Brian

2 Replies
best response confirmed by AzureBrian (Brass Contributor)
Solution

Hi @AzureBrian 

 

You've hit the nail on the head with the two options; vNET Peering or a vNET-to-vNET Gateway connection. This blog post gives you a good run down on the differences between the two:

https://azure.microsoft.com/en-gb/blog/vnet-peering-and-vpn-gateways/

As peering occurs over the private network within Azure only (there is no public traffic over a peered connection) I would implement Peering due to its lower latency and general easier administration.

 

However, if having the traffic between the vNETs encrypted is a key requirement then Gateways would be the only appropriate course of action.

 

There's no way to use routing tables on their own to achieve what you're looking for as by design vNETs are isolated from each other.

 

Hope this helps,

 

Anthony

Thanks @Anthony_Norwood for the quick response! I do indeed believe the peering will likely be the way I will go. I've used that technique before but I didn't know if it was one of the preferred methods in this scenario. Thanks again!
1 best response

Accepted Solutions
best response confirmed by AzureBrian (Brass Contributor)
Solution

Hi @AzureBrian 

 

You've hit the nail on the head with the two options; vNET Peering or a vNET-to-vNET Gateway connection. This blog post gives you a good run down on the differences between the two:

https://azure.microsoft.com/en-gb/blog/vnet-peering-and-vpn-gateways/

As peering occurs over the private network within Azure only (there is no public traffic over a peered connection) I would implement Peering due to its lower latency and general easier administration.

 

However, if having the traffic between the vNETs encrypted is a key requirement then Gateways would be the only appropriate course of action.

 

There's no way to use routing tables on their own to achieve what you're looking for as by design vNETs are isolated from each other.

 

Hope this helps,

 

Anthony

View solution in original post