I am planning to create 3 environments for my application that is hosted on Azure VM(Dev, UAT and Prod). All 3 VMs will be in same VNET. I am planning to access the UAT and Prod application through front door. For disaster recovery I have ASR replication in different region in different VNET. I am bit confused for how many static IP address do I need for this? I am assuming it will be 3 IP address, 1 for Prod and UAT each and 1 for ASR VM? Or 2 IP address will be enough? Do I need public IP address or Private IP address will work?
Thanks in advance,
Rajesh
• I would suggest you create an application gateway and host your three environments, i.e, Dev, UAT and Prod on three different VMs. Once hosted, then ensure that these are added as backend endpoint targets in the application gateway. Then, ensure that the application gateway is assigned a public IP address such that it is accessible by anyone from outside and configure the rules in the application gateway for routing the requests accordingly to the UAT and Production application through front door.
• And then, ensure that a public IP address is selected as the ‘Origin type’ and ‘Origin Hostname’ for the public IP address created in the same region is selected in the Azure front door configuration. This will ensure that the traffic that is reaching to the published public IP address is routed through the application gateway in which ‘WAF’ policy is configured. In the WAF policy, you can configure the web request filtering according to the type of request received through the front door for UAT or Production applications on the VMs.
• Finally, `create an ‘A’ host DNS record for the public IP address published as an origin type in the Azure Front door such that anyone accessing the ‘A’ host record will be redirected to the applications hosted on the VMs, i.e., Dev, UAT or Prod and furthermore, since they are accessing these through the Azure front door, the ‘WAF’ policy will take effect and filter the requests and redirect accordingly to the concerned VMs/apps. And since, for a WAF policy, an application gateway needs to be provisioned which fulfils the purpose of load balancing the requests for backend pools/VMs added in it.
In this way, you can design your infrastructure for accessing the apps hosted on VMs irrespective of static IP address but do ensure that your VMs do have a private IP address and are hosted in a private virtual network.
Related
I have the following situation:
If I deploy an application (Deployment, Service and Ingress) in my kubernetes cluster, my ingress deployment is being automatically added to my application gateway (I am using the Azure Application Gateway Ingress Controller; https://azure.github.io/application-gateway-kubernetes-ingress/annotations/ ). So far so good.
That means that my application can be reached via my application gateway via https://my-app-gateway-public-ip/myAppPath/. Also, I have an additional private DNS zone which makes my app accessible via https://dns-name/myAppPath.
Additionally, we have an AADDS in combination with a Bastion Service. Deployed some virtual machines and the virtual machines use the DNS resolver of the AADDS (for authentication against the AAD).
The problem is: If I am outside of the cloud, I can nslookup the dns or can access the site via the ip, but I cannot do that with my virtual machines. My DNS server (within the AADDS) is unable to resolve the dns or accessing the ip. I am wondering what the issue is.
The bastion and AADDS are in different subscriptions and therefore different virtual networks. I established already a peering between those virtual networks (or the authentication between the AADDS and the VMs wouldn't work).
The kubernetes cluster and the application gateway are also in a different subscription, but no peering has been done so far.
Are there any hints what I could be missing?
Kind regards
• Since, you are using a Bastion gateway server to connect to the VMs hosted in your subscription, the Bastion gateway server must be having a public IP address through which then the registered underlying VMs can be connected to via private links created in the private DNS zones associated with a particular virtual network in a subnet and an assigned private IP address and a FQDN accordingly. Thus, if you want to access the application website hosted behind the application gateway, then you will have to create a conditional forwarder in the DNS zone in AADDS to redirect the internal requests from the VMs hosted within a virtual network to the public IP address of the website hosted behind the application gateway
• Thus, a conditional forwarder forwards the DNS resolution requests for a particular resource hosted on the public internet for which the DNS host resolution is not found or done in that DNS zone which usually serves or fulfils the requests related to internal environment. As a result, when a VM configured with a private IP is registered as a host in the internal DNS zone queries the public IP or FQDN associated with the application’s website, the DNS requests are forwarded to the public internet through the conditional forwarder and then the results are displayed in the VM’s browser for the application’s webpage. Thus, the VMs don’t need to have internet access but the DNS server should have or should forward the requests through the Internet proxy server accordingly to reach the internet.
For more information on creating conditional forwarder in AADDS, kindly refer to the below link: -
https://learn.microsoft.com/en-us/azure/active-directory-domain-services/manage-dns#create-conditional-forwarders
I'm migrating asp.net services that used to exist on a physical server on-premise to Azure. However they need to reach some web-services (SOAP) that will not be migrated to azure yet. These have a public IP but I need to set the hostname in order for IIS to properly redirect the requests to the correct service as there are several on the same server. Is there any way to create some sort of DNS-server in azure that is only available for the services created in azure that can resolve to the public IP-address outside of azure? (We have used the hosts file on the servers to achieve this previously)
I tried using the private DNS Zones, but as I've understood it they can only point to other azure services within the same vnet (correct me if I'm wrong). I've also tried creating a dnsmasq docker container. However, as this is running in a Linux container, it seems that I cannot put it in the same vnet as the asp.net app services. Thus I am unable to retrieve a private IP-address that these services can use to reach the DNS server.
In my understanding it is now possible to use Azure DNS Private Zones if you want.
You would need to use regional vnet integration to point your app's traffic to a vnet that is connected to the Private Zone. You need the following settings as well, which mean that all outbound traffic from the Web App is routed through the integrated vnet first, and that the Azure default DNS server is used for DNS.
WEBSITE_DNS_SERVER with value 168.63.129.16
WEBSITE_VNET_ROUTE_ALL with value 1
https://learn.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet#azure-dns-private-zones
If you don't want to use Azure DNS Private Zones, I think you can achieve similar results by directing the Web App to use a specific DNS server. This can be done using WEBSITE_DNS_SERVER and WEBSITE_DNS_ALT_SERVER app settings (the values are the IP addresses of the servers you want to use).
This is the most authoritative public statement I can find about using these settings.
Go to the web app->settings->Application Settings-> App Settings
section
Add the following: (WEBSITE_NODE_DEFAULT) should already be
there.
a. WEBSITE_DNS_SERVER with value having the IP address of the
primary DNS server.
b. WEBSITE_ALT_DNS_SERVER (optional), with value
having the IP address of a second DNS server.
Then save the settings & restart webapp in portal.
Double check the web app can actually
connect to the DNS server: a. In kudu console, run: Nameresolver.exe
[hostname-to-lookup] [dns-server-to-use]
First argument should be the
hostname you are trying to look up, second argument is one of the DNS
servers from step 1) If this times out, there is an issue with how
your DNS servers are configured (firewalls, etc.)
https://github.com/MicrosoftDocs/azure-docs/issues/13927#issuecomment-416382230
If using these settings with a DNS server that is only accessible via private IP, you would need to use regional vnet integration again to connect to a vnet. If the DNS server is on-prem, you have to connect through the integrated vnet over VPN or ExpressRoute.
It's possible but not using the private DNS Zone.
According to Name resolution for resources in Azure virtual networks. For the scenario Name resolution from App Service Web Apps in one virtual network to VMs in a different virtual network, you need to use your own DNS servers forwarding queries between virtual networks for resolution by Azure (DNS proxy). See Name resolution using your own DNS server.
In this case, you only allow this azure web service could resolve the public IP address outside of Azure. You could enable virtual network integration for your web app, this restricts your web app access in a private network. Then you could deploy a DNS server in the same Vnet as the web app integrated VNet. You could create an A type record in your DNS zone to point to your service Public IP, then add the DNS server's IP address into the DNS server of the Integrated web app Vnet in the portal. If so, the web app could resolve this public IP via a custom DNS server.
Hope this could help you.
App Service IP Restriction for Application Gateway with WAF
I want to setup Application Gateway WAF in front of multi-tenant (non-ASE) App Service Web Apps.
I know this is possible now, according to official document.
For security, inbound traffic to Web Apps should be restricted to only allow requests for connection the application gateway Public IP. But I couldn't find the way to do it.
Idea 1. Using VNet integration:
It's not possible to using "App Service Vnet Integration" cause it's not possible to specify App gateway's VNet.
Moreover, in my understanding, VNet integration can't restrict inbound traffic.
Idea 2. Using IP Restriction config of App Service:
Application Gateway's Public IP Address can be configured as Dynamic one, Static IP Address can't be chosen.
So, I think it's not possible to specify Application Gateway's Public IP Address to IP Restriction config of App Service, cause configured IP is static but actual IP can be changed.
Any good idea?
The Application gateway IP address can change if the gateway is stopped and started by the customer.
So if you have not stop and start the application gateway, the IP address will not change.
I have an Internal application gateway configured in Azure. There is one virtual machine in the back end pool of application gateway which hosts the application. That is accessible via Intranet only.
I want the IP address of my internal application gateway to be associated to a domain name for my website?? How can i achieve this?
If you want to use a domain name, that means the application gateway needs to have a public IP address. In the gateway settings in the Azure portal, you can add a public IP address to the frontend configuration.
Looks like you already managed to put the backend of the gateway on the virtual network, that's good.
Next, you want to create a listener on the ports you need, for example 80 or 443. This is also done on the gateway configuration in the portal.
Finally, to use a domain name, you need to take the public IP address and put it in an A-record for the domain name. This would probably be in a config page with your service provider.
I had a need to add additional public IP addresses to an Azure VM and found a working solution here:
Azure VM: More than one Public IP
Essentially this creates a reserved IP in Azure and then adds the reserved IP to a cloud service. Once it's bound to a cloud service it can be mapped to a VM endpoint.
This all works great but there is one bit I don't understand - The IP address of the reserved IP and the resultant VM endpoint don't match. I have to set up DNS to point to the IP address of the endpoint to make this work. Is there something I am not doing right, or is this just the way reserved VMs work?
It looks like this unanswered question is the same issue:
azure reserved IP for VM is diffrent than the given
Thanks!
The "Azure Cloud Service" is a container that provides internet connectivity to "Azure VMs". Thus, you assign the Internet facing Public IP to the Cloud Service. This article is relatively good at explaining the relationship: Azure Cloud Services
From above link:
Here’s a definition of an Azure IaaS cloud service that will make it easy for you to understand what it is in the context of Azure Infrastructure Services:
A cloud service is a network container where you can place virtual machines.
All virtual machines in that container can communicate with each other directly through Azure (and therefore don’t have to go out to the Internet to communicate with each other).
This container is also assigned a DNS name that is reachable from the Internet.
A rudimentary DNS server is created and can provide name resolution for all virtual machines within the same cloud service container (note that name resolution provided by the DNS server is only available to the virtual machines that are located within the cloud service).
One or more Virtual IP Addresses (VIPs) are assigned to the container and these IP addresses can be used to allow inbound connections from the Internet to the virtual machines.
Certain services (like FTP) may require your vm have a public IP: Azure VM Public IP
(IaaS v1) An Azure cloud service comes with a permanent DNS name - something.cloudapp.net - and has a single VIP allocated whenever there are VMs deployed in it OR whenever a reserved IP address is associated with it. Traffic is either load balanced or NATted (port forwarded) to the VM from the Azure Load Balancer sitting on the VIP. You can also associate a public instance-level IP address (PIP) with a VM, which gives it an additional IP address. The VIP always has a DNS name (something.cloudapp.net) while the PIP has one only if you specifically add it, I did a post which goes into these differences.
(IaaS v2) VMs are not deployed into cloud services and only have a public IP address if one is specifically added - either by configuring a PIP on the NIC of the VM (and optionally giving it a cloudapp.azure.com DNS name) or by configuring a load balancer and either load balancing or NATting traffic to it. This load balancer is configured with a public IP address and can optionally have a cloudapp.azure.com DNS name associated with it. (Ignoring internal load balancers in this discussion.)