Why isn't my azurewebsites.net is still accessible after connecting to a virtual network - azure

So I have setup a web app, virtual network, application gateway using this link. I also added a virtual network gateway to the vnet so that I can integrate my web app to the vnet.
Now correct me if I am wrong but isn't the purpose of integrating your web app with virtual network to make it more secure? if so then I should only be able to access my web app through the application gateway public IP correct?
Currently when I hit the the myapp.azurewebsites.net, I get to the application.
Do I have to do something extra here?

You are mixing several different things here.
Application gateway is just a proxy (more or less). It has no control over whatever server it is routing traffic to. It cannot magically make it not accept traffic not from application gateway. That is for the server to decide (in your case you need to use web.config as far as I remember to restrict incoming IP addresses only to the IP addresses of the application gateway). So adding application gateway to the mix doesnt make it more or less secure.
Vnet integration works only one way, FROM the webapp inside the Vnet. Things inside the vnet cannot talk back to the webapp using "internal" vnet traffic, they have to use external IP address. So this wont really help you.
If you want your webapp to be available only inside the VNet your best bet is App Service Environment, but its a lot more expensive :(

Related

Azure - a simple reverse proxy with static IP

I am struggling to have a simple service acting as a reverse proxy in Azure.
I need it because the API that I want to communicate with uses IP whitelisting. That's why I want to set up a reverse proxy service with a static IP. My application (whose IP is cannot be static) would communicate with the target API via the reverse proxy.
With some research I found the following options:
Creating a Web App with some custom IIS config - I'm not sure if that's still valid, because the guides I found are pretty old
API Management - that seems pretty heavy and I've heard it's not going to be easy to configure
Application Gateway - that requires a VNet, which I do not even need.
Azure Function with Proxy - I think that option is no longer available with Functions V4. What's more, I would have to also set up NAT Gateway to have a single outbound IP. That seems overly complicated.
Creating a custom Web App with code that does the proxy logic
All these options seem to be too complicated for a simple task that I need. Basically, I want to have public reverse proxy, when I hit https://my-reverse-proxy.com/*, the proxy would return data from https://my-whitelisted-api.com/*.
Is there any easier alternative?
Most of the Azure services where you host your app has a single outbound ip or a range of outbound ip-addresses that can be whitelisted, but it's hard to know if that works in your case as you did not mention in what Azure service you host your app.
A generic solution could be that you provision an Nginx proxy in Azure Container Apps. Then you will will have the Container Apps Environment public ip address as outbound ip to whitelist. Beware though that anyone can call your proxy from any ip, which means that you are completely disabling the protection they put in place by whitelisting ips and opening up their API to the whole world. So without knowing your circumstances, this would probably not be recommended.

Azure web app access restrictions between Apps

I have 2 app service plans in the same Azure region running 1 app each - web frontend on one, API on the other.
I want to use access restrictions on the API to only allow access from the front end app.
I set access restriction rules using all the outgoing IP addresses associated with the frontend app (I note that these are exactly the same as the outgoing IP addresses on the API app as well) however when the frontend app tries to contact the API I get an error:
403 forbidden 'The web app you have attempted to reach has blocked your access.'
The 2 apps can communicate as normal when the access restrictions are removed.
I turned on diagnostic settings and ran a query on IP blocking by the app.
Turns out that the FE app is using an IPv6 address instead of the v4 addresses listed in the app properties.
This is because the app has a vnet integration set up connecting to a Subnet delegated to Webservice/serverfarm.
Azure does not make it obvious that using delegated subnets forces an integrated app to use IPv6 and there does not appear to be a way to discover what v6 addresses may be in use. MS forum response suggests any firewall rule for a web app attached to a delegated subnet should allow ALL IPv6 addresses (!!) as a way of working around the problem.
https://learn.microsoft.com/en-us/answers/questions/493483/why-is-my-azure-web-app-showing-an-ipv6-outbound-i.html
You can control the IP address of outbound traffic from your FE web app by using regional VNet integration together with a virtual network NAT gateway to direct traffic through a static public IP address. Regional VNet integration is available on Standard, Premium, PremiumV2 and PremiumV3 App Service plans. To learn more about this setup, see NAT gateway integration.
Once you FE web app has a static IP you can use that on the API web app restriction in an ALLOW rule.
If your requirement fits, you may also leverage Service Endpoints.
With service endpoints,to ensure inbound traffic to your API app comes only from the subnet used by your front-end web app.
With this route, you need to use VNet Integration with your front end app and service endpoints with your API app. Set service endpoints on the integration subnet used by your Front End application. This solution is fast to set up and easy as well.
-This feature works together with IP access restrictions. Service endpoints aren't compatible with remote debugging. There are some considerations you need to make, you may take a look at them here and also other combination of networking features available on App Service and related scenarios.
As a side note:
-IP-based access restriction rules only handle virtual network address ranges when your app is in an App Service Environment. If your app is in the multitenant service, you need to use service endpoints to restrict traffic to select subnets in your virtual network.
-On App Service, you could have those two separate apps in the same App Service Plan (ASP), since you pay only for ASP, saving costs.
So, you can continue to add apps to an existing plan as long as the plan has enough resources to handle the load. The apps in the same App Service plan all share the same compute resource.

How do I secure traffic between my VM and Application Gateway?

I have a pretty simple setup with an Application Gateway (AG), that sends traffic to a virtual machine running Ubuntu. The AG is loaded with an SSL certificate. The VM is set up to only allow incoming traffic from the AG, but it's an HTTP connection. This works, but I want to secure the traffic between my VM and AG. I can't find any relevant settings or documentation for this however.
How do I encrypt traffic between an Application Gateway and Virtual Machine? I considered a private link to at least force traffic over the Azure network, but private links only support PaaS products, where a VM is IaaS.
I assume your use the private IP of your VM in the backend settings of your Application Gateway. If so, this means that the traffic stays within your VNET and thus on the Microsoft network and also within the same region. You do not not need something like Private Link here.
So the only thing you could potentially do is to SSL-enable the endpoint on the VM and use an encrypted HTTPS connection between AppGW and your VM.
you have to do the same thing as with the api-gateway, load a certificate into de service deployed in the virtual machine and expose the API of this service using SSL protocol so the communication will be encrypted using that certificate.
The way to do it is different depending on which technology you are using to deploy your service. For example, if you are using spring-boot you can see how to do it here
https://www.baeldung.com/spring-boot-https-self-signed-certificate
However, you can use mutual-tls if you want that the only service that could connect to your VM's deployed service is the AG.
https://developers.cloudflare.com/access/service-auth/mtls

Inside load balancer in Azure

In Azure, I have 3 Web Apps (for simplicity):
Frontend website
Endpoint 1
Endpoint 2
The frontend website requests data from an endpoint.
Both endpoints are synchronized all the time (outside the scope of this question), but sometimes I need to do some maintenance on them, which gives me some downtime.
Can I somehow setup a loadbalancer only my frontend website can see, and get any of the online endpoints - like this:
The last line of this article says Internal Load Balancers might be the fit:
Can I use ILB on PaaS services (Web/Worker roles)?
ILB is designed to work with web/worker roles as well, and it is available from SDK 2.4 onwards.
Does anyone know of a guide, or have tried making this with Web Apps?
I dont think this is something you can achieve "natively" with load balancers. App Services are not actually bound to the VNet. Previously you could only use point-to-site vpn to connect them to vnet, right now there is a new vnet integration feature in preview which might allow you to use internal load balancers, but I doubt that, because they (load balancers) only allow to use virtual machines\scale sets\availability sets as backend pools.
Application gateways can be bound to the App Services. And they can be internal as well. You'd also need to restrict App Service(s) to receive traffic from anything that is not you Application gateway.
You can use traffic manager\front door for this sort of load balancing, but the endpoints won't be private

Lots of persistent requests to my web app from a private ip address

I am more a C# dev than a network admin and I am not understanding what happened.
I have a website hosted on an Azure Web App and I started to get a lot of repetitive requests from IP address 172.16.5.1, to a point that it affected the web server stability
The only way I found to fix the problem is to block this IP address, but I still have questions.
1) Is blocking the IP the best solution to the problem?
2) After googling, I found that this IP address is in the range of Private IP addresses. How can a private address reach my public web server?
3) Could it be another resource from my Azure subscription that could be making these requests?...I only have a web app configured so I don't know where these requests could come from internally
4) Can this be a DDoS attack?
This IP Address is private range as you found it, but needs more information to answer your couriosity.
I could say that’s not the best solution, you need to find out which resources on your Azure that use that IP and see why it sends a request to Web App.
This is possible when your Web App connected to the Virtual Network, discuss with your Network Admin or System Architect.
I’m quiet sure that your Web App is connected to Virtual Network or could be another instance of your Web App requesting each other.
I’m not quiet sure that was an external DDoS attack.
That appears to be the default gateway for a subnet. Check the Networking blade to see if you are integrated with a VNet. I would expect that probes from something in the VNet (AppGW, Azure Firewall, NVA, etc.) would come from the instance IP of that resource and not the default gateway, but you really need to see the subnet range and know what's in there. If this is a WebApp that is integrated with a VNet via point-to-site VPN, then maybe this is something from the VNet Gateway, like Keep Alives. That might be apparent in a network trace. Blocking that IP could result in some other service marking the WebApp as unhealthy and not routing traffic to it.
Lots of conjecture here, but like Rudy said, you're not getting an external DDOS attack from a private IP.

Resources