Let me summarize Azure networking options based on usecase:
- You need network connectivity between resources across different virtual networks in same region, you need to implement VNet peering.
- You need connectivity between resources in virtual networks spanned across different region, you need to implement Global VNet peering.
- You need network connectivity between your Organization (On-Prem) and your azure tenant and you are ok to have the secure channels over the internet, You need to implement site to site VPN gateways.
- You want network connectivity between your offices to azure tenancy with high throughput and not over internet, you need to implement Express Route.
- You need individual users to use services hsoted in your Azure tenant, you will implemnet Point-to-site VPN gateway.
All the above implementations are different on thier configurations and they each cater for each use case in its own capacity.
Here is why you need to choose Virtual WAN if you are already using more than 2 capabilities mentioned above.
- VWAN brings all of the above network connectivity implemntations under one centralized platform.
- VWAN automatically deployes one hub in each choosen region which implements Hub-spoke network design by default.
- Site-to-Site VPN gateways supports max of 10, 30 and 100 tunnels in Basic, Standard and HighPerformance SKUs. VWAN supports upto 1000 branch conncetions per VWAN hub, which can throuhput at 20GBps per hub.
- Though private communication between VNets in both VNet Peering and VWAN are ecrypted over MS backbone network, Adding additional firewall security is way easier in VWAN comapred to VNet peering.
- VWAN has most of the above services deployed across all avilability zones in a given region thus making it more relaible and scalable without any manual intervention.
- Virtual WAN provides many functionalities built into a single pane of glass such as site/site-to-site VPN connectivity, User/P2S connectivity, ExpressRoute connectivity, virtual network connectivity, VPN ExpressRoute Interconnectivity, VNet-to-VNet transitive connectivity, Centralized Routing, Azure Firewall and Firewall Manager security, Monitoring, ExpressRoute Encryption, and many other capabilities. Pick and choose what you want.
More information is available on MS Documentation. All refrence links are provided at the end of the article.
Now the title of artice is no "Why VWAN?" it says "Deploying VWAN using Terrafrom & Azure Devops". So lets jump in to deployment.
My objective is to deploy Virtual WAN, VWAN Hubs across 2 different regions, connect 2 Virtual networks in these regions via VWAN Hubs, deploy 2 Linux VMs in these VNets, have a ping from one VM to other one over VNet connectivity of VWAN and Hubs.
Step1: Create a Storage account with continer to manage your terrafrom state file.
Step2: Download the code from my Git repo.
https://github.com/pratappilaka24/Azure-VWAN
Azure DevOps is optional, as you can literally run terrafrom apply. But this needs installing terraform on your machine and AZ CLI or Azure shell for connectiing to your azure tenant.
Step 3: Create a Project in upload the code to your AZ repo.
Step 4: Create a 2 release pipelines , one for creating , the other for destroying.
Add Artifacts to depoy by adding the current project as working folder.
Step5: Start editing the stage1 by adding the below shown steps.
The only catch you might have here is that you need to point .tfvars file. It can be done by passing the name of tfvars file as a command line argument for apply and destroy steps.
Step 6: Deploy the apply release pipeline and you will see two resource groups one in AUE and USE regions. I have deployed below components as part of this project:
- 2 Resource groups in different regions
- 2 vnets
- 2 Linux VMs and supporting NSGs, NICs and OS Disks
- 1 Virtual WAN
- 2 VWAN Hubs one for each region
- 2 firewall policies and firewalls securing 2 HubsVNets
- 1 Keyvault saving the random password for the Linux VMs
Please note that the Linux VMs has SSH opened , use pasword login and have PIPs assigned to them, for easy of testing. In production envirment , aslways go for bastion and no open SSH.
Even though we open SSH, the login password (random generated pasword) will be saved to a Keyvault created in AUE resource group.
Step7: Before we login to VMs, lets check VWAN. You will find it in AUE region as shown above. Open VWAN and you can see the Hubs deployed and supporting firewalls to secure the hubs.
Click on the View Topology link in overview to see the whole hub-spoke architecture you just deployed.
Step 8: Open Firewall-policy and you can see that these will allow the private communication from IP range of one VNets to other one.
This means i can define a common set of firewall policies and apply the firewall security to communication over hubs. Now you can centrally control the policies applied to all comms across your network.
Step 9: Lastly open one of the Hubs and click "Routing Intent and Routing Policies", here you can control policies applied for the traffic over the internet and the private traffic that runs on MS backbone.
Step 10: Finally go to Keyvault and grab the VM password.
Please know that i opened SSH and addd a public IP just for our testing purpose. Else you should use bastion. Code for bastion is also there in the project files. Just uncomment it.
I login to AUE VM and try pinging the private IP of USE VM.
Same goes from USE VM to AUE VM.
If i ping the public IP, this wont work. Reason being, the firewall policy currently allow only the communcation between the private IP range of the VNets.
There now run the destroy pipeline after your testing to save money on your dev subscription 😃
Refrences:
Article by Jake Walsh helped a lot to understand and formulate this project. Big thanks to him. Link
Best place to start after exploring VWAN to know how it is advantageous over other implementations. Link
The mother of all Link
No comments:
Post a Comment