I have two VMs that are part of a kubernetes cluster. I have a single service that is exposed as NodePort (30001). I am able to reach this service on port 30001 through curl on each of these VMs. When I create an Azure application gateway, the gateway is not directing traffic to these VMs.
I've followed the steps for setting up the application gateway as listed in the Azure documentation.
I constantly get a 502 from the gateway.
In order for the Azure Application Gateway to redirect or route traffic to the NodePort you need to add the Backend servers to the backend pool inside the Azure Application Gateway.
There are options to choose Virtual Machines as well.
A good tutorial explaining how to configure an application gateway in azure and direct web traffic to the backend pool is:
https://learn.microsoft.com/en-us/azure/application-gateway/quick-create-portal
I hope this solves your problem.
So I finally ended up getting on a call with the support folks. It turned out that the UI on Azure's portal is slightly tempremental.
For the gateway to be able to determine which of your backends are healthy it needs to have a health probe associated with the HTTP setting (the HTTP Setting is the one that determines how traffic from the gateway flows to your backends).
Now, when you are configuring the HTTP setting, you need to select the "Use Custom Probe" but when you do that it doesn't show the probe that you have already created. Hence, I figured that wasn't required.
The trick to first check the box below "Use Custom probe" which reads "Pick hostname from backend setttings", and then click on custom probe and your custom probe will show up and things will work.
Related
I'm trying to serve multiple Azure App Services behind an Application Gateway. These services should only be reachable through the application gateway endpoint. To achieve this, I've done the following:
Added a VNet
Added a subnet, and added all app services to it
Added an application gateway with appropriate rules for pointing to the app service
Added access restrictions to the app service to only allow the subnet of the application gateway, and the public IP of the application gateway
The health probe of the application gateway indicates the service is healthy (and thus reachable), but when I try to make a request to the service trough the gateway using Postman, I get a 403 IP forbidden error. However, when I add my local IP as an allowed IP address to the app service, the request comes through just fine
From what I've read online, adding the public IP of the gateway should be sufficient for allowing access through the gateway, but it seems that requests from my local machine are blocked. Am I getting something fundamentally wrong here?
Edit: I also tried assigning a front-end private IP address to the gateway and adding access for that in the app service, but that also did not work
Edit 2: My configuration
Access restrictions for app service:
access restrictions
Backend pool:
Backend pool
HTTP settings:
HTTP settings
Listener:
Listener
Rule:
Rule
From your description "Added a subnet, and added all app services to it", I assume that you are meaning integrating app with Azure VNet or enable the service endpoint with Microsoft.Web for the subnet. If so, you could remove them. Both are useless in this scenario.
To restrict the access through the gateway, you only need to add the frontend IP address to the Azure App Service access restrictions. For more details, you could refer to this blog https://www.cloudmanav.com/azure/restricting-appservice-accessible-via-appgateway/#
If you have NSG associated with the subnets, you could follow the prerequisites here
https://learn.microsoft.com/en-us/azure/application-gateway/configuration-overview#network-security-groups-on-the-application-gateway-subnet
Edit
You may have redirection configured on your app service or have Azure Active Directory authentication, which causes the redirection. So when redirection happens, the client makes the request directly to app service URL Path contoso.azurewebsites.net/xxx instead of going through the application gateway URL path contoso.com/xxx.
To fix it, you could use a custom domain name to pass the same host name that the application gateway receives to the app service as well, instead of doing a host override. Get more details about this solution here.
I am trying to configure Azure application gateway WAF with a backendpool set to a VM in a different Azure tenant using its public IP address on port 443. All the SSL certificates are configured properly. However, I keep getting following error while browsing the site via WAF.
502 - Web server received an invalid response while acting as a gateway or proxy server.
I have confirmed that the NSG is on the mentioned back-end VM is allowing all traffic on port 443. What could be going wrong here?
Generally, you can check the status of Backend health in the monitoring of Application Gateway and compare with the DETAILS referring to these possible reasons on your side.
NSG, UDR or Custom DNS is blocking access to backend pool members.
Back-end VMs or instances of virtual machine scale set are not responding to the default health probe.
Invalid or improper configuration of custom health probes.
Azure Application Gateway's back-end pool is not configured or empty.
None of the VMs or instances in virtual machine scale set are healthy.
Request time-out or connectivity issues with user requests.
For each reason, you can get a solution from that link. I think you could make sure you can directly access the backend with public IP from one tenant to another tenant. Then if you have an NSG in the app gateway subnet, you must include exceptions for incoming traffic on ports 65503-65534 for the Application Gateway v1 SKU, and ports 65200-65535 for the v2 SKU. You could get more details here. You could also whitelist the app gateway public IP address in the NSG of backend VM.
Question: How do I host an endpoint in azure which allows me to redirect internet traffic at will between azure and aws services?
I am hosting two kubernetes clusters - one in Azure and the other in AWS. I want to be able to:
1. redirect the traffic at will to either aws or azure, whilst retaining the public dns endpoint.
2. fail over manually [and pref automatically too] to the aws cluster. What is the best way to host the endpoint in azure?
Requirements:
The traffic needs to be redirected immediately - no caching issues and stale loads!
Ability to configure failover - i.e. specify that Azure is hot and AWS is the failover service - the traffic should be automatically redirected as soon as Azure goes down.
I have looked at Traffic Manager, Load Balancers and Application Gateway. Not sure which one (if any) of these is best.
traffic manager wont work for you, since its a dns service, so caching will happen (admittedly its the best solution if you set dns cache to 5 seconds or something). application gateway allows you to specify an ip address as an endpoint, load balancers only work when attached to vms inside azure. But application gateways dont allow to failover at will. you would need to block the probe to failover.
Azure Front Door might be the solution for you (like the other answer mentions)
You can have a look into Azure Front Door Service for your usecase.
Look into this https://learn.microsoft.com/en-gb/azure/frontdoor/front-door-overview
I'm porting an application that was originally developed for the AWS Fargate container service to AKS under Azure. In the AWS implementation an application load balancer is created and placed in front of the UI microservice. This load balancer is configured to use a signed certificate, allowing https access to our back-end.
I've done some searches on this subject and how something similar could be configured in AKS. I've found a lot of different answers to this for a variety of similar questions but none that are exactly what I'm looking for. From what I gather, there is no exact equivalent to the AWS approach in Azure. One thing that's different in the AWS solution is that you create an application load balancer upfront and configure it to use a certificate and then configure an https listener for the back-end UI microservice.
In the Azure case, when you issue the "az aks create" command the load balancer is created automatically. There doesn't seem be be a way to do much configuration, especially as it relates to certificates. My impression is that the default load balancer that is created by AKS is ultimately not the mechanism to use for this. Another option might be an application gateway, as described here. I'm not sure how to adapt this discussion to AKS. The UI pod needs to be the ultimate target of any traffic coming through the application gateway but the gateway uses a different subnet than what is used for the pods in the AKS cluster.
So I'm not sure how to proceed. My question is: Is the application gateway the correct solution to providing https access to a UI running in an AKS cluster or is there another approach I need to use?
You are right, the default Load Balancer created by AKS is a Layer 4 LB and doesn't support SSL offloading. The equivalent of the AWS Application Load Balancer in Azure is the Application Gateway. As of now there is no option in AKS which allows to choose the Application Gateway instead of a classic load balancer, but like alev said, there is an ongoing project that still in preview which will allow to deploy a special ingress controller that will drive the routing rules on an external Application Gateway based on your ingress rules. If you really need something that is production ready, here are your options :
Deploy an Ingress controller like NGINX, Traefik, etc. and use cert-manager to generate your certificate.
Create an Application Gateway and manage your own routing rule that will point to the default layer 4 LB (k8s LoadBalancer service or via the ingress controller)
We implemented something similar lately and we decide to managed our own Application Gateway because we wanted to do the SSL offloading outside the cluster and because we needed the WAF feature of the Application Gateway. We were able to automatically manage the routing rules inside our deployment pipeline. We will probably use the Application Gateway as an ingress project when it will be production ready.
Certificate issuing and renewal are not handled by the ingress, but using cert-manager you can easily add your own CA or use Let's encrypt to automatically issue certificates when you annotate the ingress or service objects. The http_application_routing addon for AKS is perfectly capable of working with cert-manager; can even be further configured using ConfigMaps (addon-http-application-routing-nginx-configuration in kube-system namespace). You can also look at initial support for Application Gateway as ingress here
We have a set-up an azure gateway of tier WAF V2 (so it would be zone-redundant). It has a backend pool containing 2 WebApps -AppServices (supposedly a Primary and a Secondary).
The idea behind it was to use the gateway similarly to priority traffic manager: Routing usually to the primary WebApp, and only routing to the secondary WebApp in case the first one goes down.
The Problem is that the only way I found to do that is to order the rules associated with the listeners of the backend pool (because I believe azure prioritizes them according to the order they are listed). But given that both Apps are in the same backend pool, Im unsure of how to do that.
So now the gateway randomly routes to either the first or second WebApp.
Any advice or suggestions would be much appreciated,
Thank you
Note: Also we have tried setting a traffic manager in between the gateway and the WebApps, but the gateway keeps connecting to the primary WebApp even when its down and its probe becomes of health status unknown.
Application Gateway is a layer 7 load balancer, which means it works with web traffic only (HTTP/HTTPS/WebSocket). It supports capabilities such as SSL termination, cookie-based session affinity, and round robin for load balancing traffic. This indicated that the application gateway frontend randomly distribute the incoming traffics to the endpoint if both endpoints are healthy. So you could see the gateway randomly routes to either the first or second WebApp. See the application gateway FAQ. The app gateway does not work like priority-based traffic manager which always requests to the primary web app unless the primary web app is unhealthy.
About the health status unknown, the most common reason is that access to the backend is being blocked by an NSG or custom DNS. Ref: Troubleshooting bad gateway errors in Application Gateway