I am drawing network architecture for my solution based on Azure. One of the ask is to list the network protocols used for inter-resource communication (e.g. Azure Storage to Data Factory). I tried to get a comprehensive view in Azure documentation but couldn't reach to get what I wanted.
May I take your help to understand the network protocols used in the following scenarios?
Azure VNET to VNET
Communication between Azure PaaS services (since PaaS services are web pages, are they by default use HTTPS)?
Azure VM to PaaS service like Azure SQL
Azure VNET to VNET
• When communication between two virtual networks happen in Azure, the network protocols used in this scenario depend on the type of resources deployed in it, i.e., hosted in that virtual network. By default, only TCP, UDP and ICMP TCP/IP protocols are allowed within the virtual networks for communication purposes. DHCP via unicast (over UDP port 68 and 67) and UDP source port 65330, Multicast, Broadcast, IP-in-IP encapsulated packets and Generic Routing Encapsulation (GRE) packets are blocked within VNETs.
Communication between Azure PaaS services (since PaaS services are web pages, are they by default use HTTPS)?
• Communication between Azure PaaS services also depends on the type of communication that happen between them through the underlying resources and services that they offer. Also, mostly the communication between Azure PaaS services is TCP HTTPS protected by TLS 1.2 encryption level security certificates ensuring the security of the communication channel and protected by default Microsoft FQDN for the services.
Azure VM to PaaS service like Azure SQL
• The communication protocol between the Azure VM and Azure SQL is purely over TCP/IP over a specified and dedicated port for SQL transactions like 1433.
Related
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
I've got an Azure app service that I'd like to use to run some software that requires licensing. The license is provided via a server on our internal network. The issue being finding a way to connect to this server.
The first option is to provide a fixed license that ties to the MAC address. However I don't think this will be possible from an app service, as it does not really have a MAC address? Can I provide a VNI to it and obtain a fixed MAC address that way?
What other options are there? Can the app service be tied to a VNET that can tunnel to the on-premises resource? Should I use a VM with a VNI instead of an app service? Any resources on these kind of problems would be appreciated.
I have used Azure Relay to connect my on-prem service with my app service. Not sure if you have already considered this option.
If your requirement is to establish a connection between your on-prem service and you app service, check out this https://learn.microsoft.com/en-us/azure/service-bus-relay/relay-what-is-it
Hope this helps
You could use VNet Integration with Azure App service and Azure VPN gateway to connect to on-premise resources. VNet Integration is used only to make outbound calls from your app into your VNet. There are Regional VNet Integration and Gateway-required VNet Integration.
How regional VNet Integration works
Regional VNet Integration works by mounting virtual interfaces with
addresses in the delegated subnet. Because the from address is in your
VNet, it can access most things in or through your VNet like a VM in
your VNet would. The networking implementation is different than
running a VM in your VNet. That's why some networking features aren't
yet available for this feature.
How gateway-required VNet Integration works
Gateway-required VNet Integration is built on top of point-to-site VPN
technology. Point-to-site VPNs limit network access to the virtual
machine that hosts the app. Apps are restricted to send traffic out to
the internet only through Hybrid Connections or through VNet
Integration. When your app is configured with the portal to use
gateway-required VNet Integration, a complex negotiation is managed on
your behalf to create and assign certificates on the gateway and the
application side. The result is that the workers used to host your
apps are able to directly connect to the virtual network gateway in
the selected VNet.
For more information, you could read this blog---How to Connect Azure Web Apps To On-Premises
In addition, If you need more control of the application deployment and less scale out or in than the Azure app service. You could host your application on the Azure VM, then set up a VPN gateway in that VNet where Azure VM locate, it allows access to the on-premise resources from your Azure VM as usual in the internal network.
I was able to find that Google Cloud makes sure that any requests which move out of its physical environment undergo mandatory encryption, refer to (pg6 under heading Virtual Machine to Virtual Machine of) this link
Do Azure (and AWS) follow a similar procedure? I would appreciate if someone can point me to an official link. I was not able to find it in Azure docs.
Thanks
Azure supports various encryption models, including server-side encryption, client-side encryption, Azure disk encryption and so on. Read Azure encryption overview.
For data in transit, you will see that Azure always encrypt traffic between your cloud-hosted resources and external networks or the public internet.
Data in transit is data moving between resources on the internal,
between datacenters or external networks, or over the internet.
Data in transit is usually encrypted by requiring SSL/TLS protocols
for network traffic. Always encrypt traffic between your cloud-hosted
resources and external networks or the public internet. PaaS resources
typically enforce SSL/TLS encryption by default. Your cloud adoption
teams and workload owners should consider enforcing encryption for
traffic between IaaS resources hosted inside your virtual networks.
Azure VM in Azure is not an individual resource. It must be deployed in an Azure virtual network, which is the fundamental building block for your private network in Azure. VNet enables Azure VMs, to securely communicate with each other, the internet, and on-premises networks. You also could secure VNet using the network security group. So, the internal traffic between two VMs in a VNet is secure. If the VMs in different VNets, you cloud peer two VNets with each other. The traffic between VMs in the peered virtual networks is routed through the Microsoft backbone infrastructure, much like traffic is routed between VMs in the same VNet, through private IP addresses only.
Even the traffic in an Azure VNet is secure but the HTTP request is not secure by default. HTTP requests and responses are sent in plaintext, which means that anyone can read them. HTTPS corrects this problem by using TLS/SSL encryption. You could also consider using HTTPS requests.
Hope this could help you.
Please suggest if we can access on-premises MS SQL Server Database from Azure Web App behind ASE.
My understanding is that we just need to get sql port opened on firewall for connectivity from ASE subnet to on-premises subnet.
You could but there are other ways like Hybrid connections:
Within App Service, Hybrid Connections can be used to access application resources in other networks. It provides access from your app to an application endpoint. It does not enable an alternate capability to access your application. As used in App Service, each Hybrid Connection correlates to a single TCP host and port combination. This means that the Hybrid Connection endpoint can be on any operating system and any application, provided you are accessing a TCP listening port. The Hybrid Connections feature does not know or care what the application protocol is, or what you are accessing. It is simply providing network access.
https://learn.microsoft.com/en-us/azure/app-service/app-service-hybrid-connections
Other choice is VPN or Expressroute
https://learn.microsoft.com/en-us/azure/app-service/environment/network-info
Is it possible to change the port that the azure server uses? I currently only see the ability to add IP addresses that can be used to access the server. Or is it required that firewalls allow port 1433 outbound traffic?
Assuming you're referring to SQL Database Service and its associated firewall, no: You may only add IP addresses to the firewall, for access.
There is no ability to change the port that the service listens on. You'll need to allow for outbound traffic on port 1433, if you want to access the database remotely.
Also, just FYI - port 1433 is the standard SQL Server port.
Note: The inability to change the listening port is strictly for the SQL Database service. This restriction doesn't exist for SQL Server running in a VM, since you have total control of inbound ports and related port-mapping via network security groups.
A year+ later a lot has changed with Azure. There are a ton of offerings to help "bypass" internal firewalls for port 1433 and integrating with the services in Azure.
Azure is attempting to help developers with Synchronous Hybrid Connectivity to on premise datasources or visa versa. My personal opinion would be for you to use On-Premises Data Gateway. Here are a few options to help with the port 1433 constants:
WCF Relay
Service Bus offered relays almost from the beginning of Azure
Built on the WCF capability. Security was originally ACS, but now SAS
can be consumed by lots of different tech, eg biztalk, soap, rest, crm online and is very reusable
Hybrid Connections
Built on Web Sockets so not confined to Windows. API accessible for other scenarios.
Azure Virtual Network
Point-to-site virtual private network (VPN):
Established between a single PC connected to your network and the VNet.
Uses the SSTP protocol to provide encrypted communication over the Internet between the PC and the VNet. The latency for a point-to-site VPN is less predictable, since the traffic traverses the Internet.
Site-to-site VPN:
Established between your VPN device and an Azure VPN Gateway.
Connection is an IPSec/IKE VPN that provides encrypted communication over the Internet between your on-premises device and the Azure VPN gateway.
The latency for a site-to-site connection is less predictable, since the traffic traverses the Internet.
Azure ExpressRoute:
Established between your network and Azure, through an ExpressRoute partner.
This connection is private. Traffic does not traverse the Internet.
On-Premises Data Gateway
Acts as a bridge between Azure PaaS and on-prem resources. Works with connectors for Logic Apps, Power Apps, Flow & Power BI:
When you connect to SQL azure database,it connects through port 1433 by default and you can't change it..
You have to enable outbound rule to allow traffic for SSMS to connect with Azure