We are trying to host multiple sites at the backend of Azure Firewall, however we have about 30 different sites and each with their own test\dev and UAT site, which means 30 x 4 and 120 sites, each one is hosted on port 443, all have their own public IP, and are configured with a DNAT rule for directing the traffic based on the source to the correct backend, we have considered a Azure Application Gateway, with host header redirect, but we haven't had a chance to implement it yet, I was wondering is there a way to be cleverer and use Azure firewall with less public IP's and route to various backends, also the prod public sites have no source specified as they're open to the public.
Hope I've explained that clearly. Thanks
• Yes, what you are trying to achieve is very much possible by creating backend pools of websites according to their purpose, common domain name or the URL path routing. For this purpose, you can use the Azure application gateway efficiently by configuring it with the required features given in it.
First, you can define wildcard hostnames in multiple site listeners for up to 5 hostnames per listener, i.e., suppose you have three domain names under which the multiple various web sites are hosted, then you can create pools of public IP addresses under that respective domain name and ensure that the request for that domain’s website is routed accordingly in application gateway. Similarly, you can host multiple subdomains of the same parent domain on the same application gateway deployment.
For more information on configuring the above, kindly refer to the documentation link below: -
https://learn.microsoft.com/en-us/azure/application-gateway/multiple-site-overview#wildcard-host-names-in-listener
• Also, you can distinguish the requests to each one of the websites with a public IP address by configuring URL based path routing rules for either each one of them or categorizing them into pools of common domain name, common URL path, content to be fetched, common purpose or any such characteristic through which you can make a collection of them. URL Path Based Routing allows you to route traffic to back-end server pools based on URL Paths of the request. One of the scenarios is to route requests for different content types to different backend server pools. Thus, in this way, you can route requests to backend website pools by defining the correct required parametric configurations.
For more information on configuring the above, kindly refer to the documentation link below: -
https://learn.microsoft.com/en-us/azure/application-gateway/url-route-overview\
Also, you can configure request routing rules based on combining the above two features in one. For more information regarding this, kindly refer to the documentation link below which describes in detail when and how you should configure the various path based and listener-based rules in application gateway: -
https://learn.microsoft.com/en-us/azure/application-gateway/configuration-request-routing-rules
Related
Some of my apps are not working from some customers site, I later discovered that this was because I am using the default websites for my app hosting that is the url is myapp.azurewebsites.net which was not whitelisted on the customers firewall. The customer whitelisted my website domain name and its sub domain names .i.e mywebsite.com and *.mywebsite.com are all whitelisted.
If i were to create CNAME record which has a CNAME pointer to the azure default web app for example myapp.mywebsite.com points to myapp.azurewebsites.net, will this get around the issue ? Or do I need to whitelist myapp.azurewebsites.net Or its IP address that is the IP address of myapp.azurewebsites.net ?
Firstly, by default, apps hosted in App Service are accessible directly through the internet and can reach only internet-hosted endpoints. So, typically, anyone with the URL without any specific local network/firewall/proxy restrictions can access the WebApp URL.
As I understand, your WebApp is open to the public and only a few users (on a specific network), have trouble accessing the site. Plus, there are no access restrictions that you have implemented from the WebApp side.
Just to highlight,
Network administrators often deploy proxy servers, firewalls, or other
devices, which can help secure and give control over how users access
the internet. Rules designed to protect users can sometimes block or
slow down legitimate business-related internet traffic. This traffic
includes communications between you and Azure over the URLs listed
here.
Reference : Allow the Azure portal URLs on your firewall or proxy server
So, on case-case basis, for the affected network, you may have them add appservice.azure.com (Azure App Services) in the allowed list.
Or
As your customer performed – “The customer whitelisted my website domain name and its sub domain names .i.e mywebsite.com and *.mywebsite.com are all whitelisted.” have them add the URLs to allowedlist.
Or
Since IP address of your WebApp (see the reasons for the change), the best route would be for you to set up a custom domain for your WebApp.
Kindly check this doc - Tutorial: Map an existing custom DNS name to Azure App Service
The CNAME maps to the app's default hostname instead, which is less susceptible to change. | | Wildcard | *.contoso.com | CNAME record. |
-- As a side note (as indicated above), by setting up access restrictions, you can define a priority-ordered allow/deny list that controls network access to your app. Which is the opposite of your scenario, just sharing as FYI, in case you wish to know about access restrictions from WebApp side. Set up Azure App Service access restrictions
I have a question about azure front door potential for this. So I have 2 web site running by Azure App Services and I need then under same domain name but different path of URL like this:
App Service A -> www.something.com
App Service B -> www.something.com/b-product
I'm not sure this is possible to use Azure front door or I should use another service to solve this problem.
Do somebody can suggestion to me?
Yes you can do this fairly easily, when you create your routing rule you have the option tom specify patterns to match, there you can specify /foo and have this forwarded to pool A where app service A lives
Then you create a different routing rule with /bar pattern to match and forward that to pool B
Then you can repeat this until you get what you need.
you can also have one routing rule match the / domain as per your example you don't have to use a /foo pattern you can also do /* but I always found it easier to use /foo/* and /bar/* to keep the same URL structure
As suggested by Junnas , you can use the front door rules engine
Alternatively , you can use application gateway listeners
If you want all of your requests (for any domain) to be accepted and forwarded to backend pools, choose basic. Learn how to create an application gateway with a basic listener.
If you want to forward requests to different backend pools based on the host header or host names, choose multi-site listener, where you must also specify a host name that matches with the incoming request. This is because Application Gateway relies on HTTP 1.1 host headers to host more than one website on the same public IP address and port. To learn more, see hosting multiple sites using Application Gateway.
I have a storage account in Azure with a container named clients. Inside the container I have folders for various clients, i.e:
mysite.blob.core.windows.net/clients/one
mysite.blob.core.windows.net/clients/two
I also have my own site set up as a static website, i.e:
mysite.z33.web.core.windows.net
On top of that, I have a custom domain: mysite.com. Is it possible, using Azure CDN or Azure Front Door/Application Gateway to route traffic like so (in a way that doesn't require further configuration per client):
one.mysite.com -> mysite.blob.core.windows.net/clients/one
two.mysite.com -> mysite.blob.core.windows.net/clients/two
mysite.com -> mysite.z33.web.core.windows.net
So far I have tried doing this with Azure CDN but I don't think it's possible, it has a rules engine that seems quite flexible but I don't think they support wildcard domains, unless I'm (hopefully) wrong. Ideally I'd like it to be done in some sort of wildcard way, so that is maps:
<client>.mysite.com -> mysite.blob.core.windows.net/clients/<client>
I don't really want to have to add more rules or configuration every time I have a new client.
In fact, you could use an alias record to add a root domain as the custom domains in your CDN endpoints if you use Azure CDN to host your DNS zone. In this case, you need to set up multiple endpoints for each custom domain. See this document for more details. But Pointing a zone apex to CDN endpoints for Azure CDN from Akamai is currently not supported. You can use other CDN price tier.
If you use the Azure application gateway, you may configure multiple sites listener to receive different incoming host traffic and use path-based URL rules to route the traffic to the backends. It looks like a complex configuration and hard to troubleshoot the app gw related issue.
The azure front door should also do this trick, it supports onboard a root domain on your Front Door also allows wildcard domains. The route path is also easy to configure. See path matching for more details.
Hope this information could help you.
We have web apps hosted on two data centers for high availability and we used traffic manager with round robin routing method to route traffic to either of the two data centers.
Now per business requirement, we need route the traffic by URL pattern. Say, for url /api/v1, route to data center 1, for url /api/v2, route to data center 2.
I know traffic manager does not support url based routing. Any workaround?
Azure Traffic Manager operates at the DNS layer and as such does not know any details about the URL related to the DNS request it receives - therefore URL based routing is not possible with Azure Traffic Manager. I encourage you to consider using Azure Application Gateway for URL based routing within a single region. For inter-region routing based on URLs, you could consider making the subdomains different and using DNS layer routing.
We try to migrate our Platform from classical IIS hosting to a service fabric micro service architecture. So fare we learned that a service fabric lives in a virtual machine scale set and uses Load balancer to communicate to the outside world.
The Problem we now facing is that we have different access points to our application. Like one for browser, one for mobile app. Both use the standard https port, but are different applications.
In iis we could use host headers to direct traffic to one or the other application. But with service fabric we can’t. easiest way for us would be multiple public IP’s. With that we could handle it with dns.
We considered a couple solutions with no success.
Load balancer with Multiple public ip’s. Problem: it looks like that only works with Cloud Services and we need to work with the new Resource Manager World there it seems to be not possible to have multiple public ip’s.
Multiple public load balancer. Problem: Scale Sets accept only on load balancer instance pert load balancer type.
Application Gateway. Seems not to support multiple public ip’s or host header mapping.
Path mapping. Problem: we have the same path in different applications.
My questions are:
Is there any solution to use multiple IP’s and map the traffic internally to different ports?
Is there any option to use host header mapping with service fabric?
Any suggestion how I can solve my problem?
Piling on some Service Fabric-specific info to Eli's answer: Yes you can do all of this and use an http.sys-based self-hosted web server to host multiple sites using different host names on a single VIP, such as Katana or WebListener in ASP.NET Core 1.
The piece to this that is currently missing in Service Fabric is a way to configure the hostname in your endpoint definition in ServiceManifest.xml. Service Fabric services run under Network Service by default on Windows, which means the service will not have access to create a URL ACL for the URL it wants to open an endpoint on. To help with that, when you specify an HTTP endpoint in an endpoint definition in ServiceManifest.xml, Service Fabric automatically creates the URL ACL for you. But currently, there is no place to specify a hostname, so Service Fabric uses "+", which is the strong wildcard that matches everything.
For now, this is merely an inconvenience because you'll have to create a setup entry point with your service that runs under elevated privileges to run netsh to setup the URL ACL manually.
We do plan on adding a hostname field in ServiceManifest.xml to make this easier.
It's definitely possible to use ARM templates to deploy a Service Fabric cluster with multiple IPs. You'll just have to tweak the template a bit:
Create multiple IP address resources (e.g. using copy) - make sure you review all the resources using the IP and modify them appropriately
In the load balancer:
Add multiple frontendIPConfigurations, each tied to its own IP
Add loadBalancingRules for each port you want to redirect to the VMs from a specific frontend IP configuration
Add probes
As for host header mapping, this is handled by the Windows HTTP Server API (see this article). All you have to do is use a specific host name (or even a URL path) when configuring an HTTP listener URL (in OWIN/ASP.NET Core).