We are setting up infrastructure in Azure with Hub-n-spoke model and planning to implement hub-n-spoke model with one hub and two spoke. The requirement is,
— Spoke to Spoke communication to be secure: The communication between spoke (VNET-to-VNET) will happen through VNET peering, and we found that MACsec encryption at layer2 gets applied by MS Azure by default. I think we are good on this, correct me if I am missing something. Reference
— Communication between VMs inside VNET to be secured: We see some guidance from MS Azure for Windows VMs to make use of SMB3.0 for securing data in transit between the VM inside VNET. However, we don't see any recommendation or guidance from MS Azure to secure data in transit between Linux (CentOS) VM within VNET. Any inputs to achieve this would be a great help.
Note: As per the article from gooogle (especially referring to the diagram), we see VM to VM communication gets encrypted by default inside GCP VPC. We are looking for similar feature in Azure. Please share inputs on this to achieve.
Related
I was told recently that the Hub VNET is only used in case there is on-premise networking to/from considerations.
I am quite surprised as were many, at the table.
I was under the impression if I have, say, a AZURE Cloud only env. that I could still have a Hub Spoke approach. Or is this not so? What would be the preferred non-Hub Spoke approach if there is peering or inter-VNET access required?
I am aware of VNET Peering and other methods to access resources in other VNETs, API's and Private Link.
The hub-spoke approach works great in some scenarios in cloud-only environments - although in most of docs or architectural patterns Microsoft shows it together with on-prem connectivity.
I used it frequently when we shared some resources like ACR, Log Analytics or simply to host a jump host (with Bastion) to access resources in other networks.
One of the most common scenarios is also the Azure Monitor Private Link Scope, where the hub-spoke topology is recommended:
https://learn.microsoft.com/en-us/azure/azure-monitor/logs/private-link-design#hub-and-spoke-networks
In an Azure Cloud only environment, you can still have a Hub-Spoke approach and this is the recommended one.
While you can cross-peer different spokes to form a Mesh for spokes to exchange data (in a non-Hub scenario), this will become complicated as the number of spokes increases. You will have to configure 1:n Peering in every VNet.
With Hub-Spoke model, you have to route spoke-spoke traffic via Hub Vnet, but the advantage here is that the Hub Vnet becomes the single point entry for the environment and you can deploy resources here that would be shared and used by all other VNets (such as custom DNS server, Firewall)
can anyone explain difference between Azure Application Gateway, Virtual Network Gateway, Virtual WAN, ExpressRoute, Arc and Private Link, please?
It seems to me all services are pretty similar helping with connecting either on-prem to Azure, in-Azure to in-Azure or public to Azure.
They're similar in that they all involve network traffic, but that's pretty much where the similarities end.
Application Gateway is a Layer 7 load balancing service with advanced features like SSL termination. It's used to route client requests to your applications.
Virtual Network Gateway is a VPN gateway for point-to-site (user) and site-to-site (office/datacenter) VPN connections to your own Azure VNETs. This would, for example, allow you to RDP into Azure VMs from your on-prem office using their private IPs.
ExpressRoute is similar to site-to-site, however it doesn't use IpSec tunnels, it's a dedicated, unencrypted connection from your location directly into Microsoft's backbone. (i.e. you don't traverse the public internet). There's no encryption and the connection is faster. This is a service you need to work with a 3rd party internet provider to implement.
Virtual WAN is more like a networking hub where there would be many site-to-site, point-to-site, ExpressRoute, etc... connections spanning a wide area (as the name implies). This would be for large enterpise organizations with many on-prem locations.
Arc is a means of adding your on-prem resources into Azure for management. e.g. you have a physical server somewhere and you want to manage it though ARM/portal.
Azure Private Link is a feature of many Azure services (storage, SQL PaaS, etc..) which allows you to create a private DNS record and assign a private IP address on your internal VNETs. This is used when you want to disable all public network access to a resource and only allow access from within your own VNET.
I have barely scratched the surface of the differences here, but suffice it to say, there are many differences. From this page, you can type the service name into the search and get more specific details on the offering. Hope this helps.
https://learn.microsoft.com/en-us/search/?terms=networking%20in%20azure
We have a client who wants to connect their premises to Azure. Their main hindrance at this point is determining the best way to connect to Azure given their current connectivity configuration. They have two redundant ISP connections going to the head office for internet access. They want to be able to configure a VPN connection to Azure that would operate in a similar way i.e. if ISP A went down it would seamlessly use ISP B and vice versa. The normal multi-site VPN configuration does not fit this since there is one local network behind which means the network behind separate VPNs over each ISP would have overlapping IP address ranges which is not supported. Is such a configuration possible? (See diagram below)
Either that or is there a way to abstract the two ISP connections onto one VPN connection to Azure.
They’re currently considering using a Cisco ASA device to help with this. I’m not familiar with the features of this device so I cannot verify if it will solve their issue. I know there is also a Cisco ASAv appliance in the Azure marketplace don't know if that could also be a part of a possible solution if they went with such a device.
required vpn configuration
The Site-to-Site VPN capability in Azure does not allow for automatic failover between ISPs.
What you could do are the following
- Have automation task created that would re-create the local network and gateway connection upon failover. Manual and would take some RTO to get it up and running
- Use the Cisco CSRs to create a DMVPN mesh. You should be able to achieve the configuration you want using that option. You would use UDRs in Azure to ensure proper routing
I havent done it in Azure, but here is what you do in AWS (And I am sure there would be parallel in Azure)
Configure a "detached VGW" (virtual Private gateway) in aws. Use DMVPN cloud to connect CSRs to multi-site on-prem.
Also, for failover between ISPs you could have a look at DNS load balancing via a parallel to AWS's Route 53 in Azure.
Reference thread :
https://serverfault.com/questions/872700/vpc-transit-difference-between-detached-vgw-and-direct-ipsec-connection-csr100
We are building a saas application over Azure. We want to provide 'Virtual Network feature (optional)' to client. If client subscribe for 'Virtual Network', we are planning to wrap VM's into virtual network and allow him to connect to his local network.
But in case two clients choose this feature, we will have to create separate VNet over same VM (since our application is running on same VMs).
Is this feasible or we are working on wrong direction?
Thanks In Advance
The architecture you are suggesting will not work in Azure (nor in AWS either). You would first require multiple NICs in VMs which are not currently supported in Azure.
With the lack of native SSAS support on Azure I am inclined to install it on a VM Role. I want to know if this sounds like a feasible option. Questions that come to mind:
It sounds like the VM drive is persisted on Azure Storage. Is this efficient for holding a SQL Server installation? Or are the drives not durable at all?
Can this VM be able to communicate with SQL Azure, Worker Roles, and Web Roles?
Can SSAS be accessed by Worker Roles and Web Roles?
If the answer to 2 or 3 is yes. Would the traffic be considered internal traffic or would it be subject to data transfer rates?
Thanks,
Yes - with the latest Virtual Machine announcements the drives are durable. So you can install SSAS on a VM along with SQL Server. Check out the details of the preview program here: https://www.windowsazure.com/en-us/home/features/virtual-machines/
A VM can communicate to SQL Azure like an other application as long as you open up the firewall to allow internal connections. I am not sure what you mean by accessing Worker Roles from a VM; what do you have in mind? Generally speaking you can access other endpoints through URLs; beware however that IP Addresses can change, so it's a good idea to have formal URLs for machines/end points you are trying to connect to.
The reverse is true as well; worker roles can communicate with other endpoints; just don't use IP addresses because they could change on you.
If you are deploying all your services within the same data center in Azure, it would all be internal traffic, so you would not be charged for that traffic.
The answers are as below:
Yes. You sure can use SQL Server 2008/2012 on any Azure VM. Be sure to have larger VM for better performance.
Yes, you can connect directly to Azure VM in between role as long as you have opened proper ports. As long as all machines are in Same DC this will not have any problem or need any special configuration.
Yes. #2 applies.
As long your egress/ingress is between all those machines are within same DC, it is all considered internal traffic.