In the previous blog post, we covered Azure Site-to-Ste VPN. As part of the Azure AZ-700 Study Guide, this blog post continues with another hybrid networking technology that allows client endpoints to connect to Azure vNet infrastructure. Besides connecting your headquarter and branch office networks to Azure, it is also vital to have an infrastructure to provide connectivity to your mobile users. Using Point-to-Site Virtual Private Network(P2S VPN), client endpoints can connect and use Azure services. You can implement P2S VPN on Route-based Azure VPN gateways and provide a secure connectivity option to your users.
Design and implement a hybrid networking infrastructure is part of every cloud adoption project. Organizations planning to embrace public cloud services and migrate resources to Azure usually need communication channels between the on-premises environments and Azure. One of the widely used technologies that provide the required communication channel is Site-to-Site Virtual Private Network (S2S VPN). To deploy such a communication channel, you will set up a VPN IPSec tunnel between an On-premise gateway and Azure VPN gateway. As part of the Azure AZ-700 Study Guide, in this blog post, we are going to explorer Azure S2S VPN
A few days ago, Microsoft introduced a brand new certificate titled Azure Network Engineer Associate. Since networking is one of the core elements of any cloud infrastructure, it is crucial to educate the Subject Matter Experts in planning, implementing, and maintaining Azure networking solutions. AZ-700: Designing and Implementing Microsoft Azure Networking Solutions exam should be taken and passed successfully to achieve this certificate. As a firm believer of certification programs and someone who has been working in the IT industry for quite a long time, I would recommend taking the training and AZ-700 exam to those who work with Azure networking. The reason behind believing in the certification programs is you will learn the required concepts based on a proven learning framework.
On May 25, a critical vulnerability reported which affects vCenter Server 6.5, 6.7 and 7.0 and VMware Cloud Foundation 3.x and 4.x. With access to port 443 of vCenter Server, an attacker may exploit this issue to execute commands with unrestricted privileges on the operating system that hosts vCenter Server. This issue arise because of lack of input validation in vSAN Health Check plug-in.
Before jumping to NSX-T Distributed Firewall (DFW) concept and rule creation, I want to point out why this solution is important and what security issues can be addressed by using this powerful solution. Building a zero trust model security has been the biggest concern of network and security teams. In traditional data centers, high-level segmentation is built, which could help to prevent various types of the workload from communicating. But the main challenge of the legacy security model is data centers facing a lack of lateral prevention communication system between workloads within a tier. In other words, traffic can traverse freely inside a network segment and access the crucial information until it reaches the physical firewall to get dropped. In addition, implementing different layers of security and firewalls would cause complexity and cost.
NSX-T Distributed Firewall (DFW) is a hypervisor kernel-based firewall that monitors all the East-West traffic and could be applied to individual workloads like VM and enforce zero-Trust security model. Micro-segmentation logically divides department or set of applications into security segments and distribute firewalls to each VM.
After upgrading to vCenter 7 Update 1 , when I tried to browse vCenter HTML5 UI, I faced “no healthy upstream” error. I could access to vCenter Management Interface (VAMI) https://vCenter-IPaddress:5480 without any issues. I could also connect to vCenter Server through SSH but I realized couple of vCenter Server services could not start.
In the previous blogpost we went through Azure VMware Solution(AVS) IPSec VPN setup and to complete hybrid networking between on-prem and AVS we need to configure NSX-T gateway too. As we discussed the target architecture would look like the following diagram.
When it comes to connecting an on-premises VMware environment to Azure VMware Solution(AVS), ExpressRoute is the recommended & preferred connectivity method. But in some cases using a VPN tunnel is the only viable connectivity solution to AVS environment.
NSX-T Tier-0 or Tier-1 gateways could be used to connect on-premises VMware environment to AVS. On the Azure side, Virtual WAN(vWAN HUB) will be provide the transit connectivity through a ExpressRoute Gateway into AVS infrastructure. I am going to walk you through the configuration of both NSX-T Tier-1 GW and Azure Virtual WAN to have a complete setup.
Starting with version 4.7.100, VxRail supports vSAN 2-Node for small and Remote-Office Branch-Office (ROBO) deployments. This solution works best for environments that needs hyperconverged compute and storage with a minimal configuration. VxRail 2-Node consists of two VxRail E560 nodes and a vSAN Witness Appliance. It is recommended to deploy the Witness appliance in another site but in case of lacking another site it can be deployed in the same site as vSAN 2-Node.
There are some considerations and requirements that you need to have it in place before starting the VxRAIL 2-Node implementation.
When it come to setting up a hybrid cloud environments, one of the most important topics is networking. It is usually comes down to stretch on-prem network segments to the public cloud environment. This blog post is going to simply describe NSX-T architecture on AVS as the default networking and security stack. If you are new to AVS you can read Introduction to AVS blog post first, and then continue with this article.
