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
Related
I have to configure my Microsoft Azure server like below scenario
So it is like a request comes with a public IP which represents application gateway having SSL and the request passes from app gateway to the load balancer.
LB just forward to the virtual machine(having SSL) on the basis of the port number.
Here there is only one public IP and virtual machine selected according to the port.
I made the configuration but the only thing I am missing that is SSL configuration with Application gateway and same SSL in a virtual machine.
I don't know my configure pattern is right or wrong please suggest me if you have a good option.
My goal is to achieve the request (with the public IP) passes from the application gateway having SSL to the virtual machine also having the same SSL on the basis of ports with the same public IP, Is there any better option than my configuration pattern?
Please help me, How to achieve it.
You can use the following Settings in Application Gateway and you don't need ILB in-front of your VM.
Create a Application gateway. Create 3 Multi-site Listener. Upload Certificates and enter Host Name and the respective ports.
Create 3 Backend Pool and add your VMs to it.
Create 3 HTTP Settings. Upload authentication certificates and configure respective ports. Create and attach Health Probes to HTTP Settings.
Create rules where you link corresponding listeners with HTTP Settings and backend pool.
Check if the Health Probes are healthy. If yes, then your setup is complete.
In Application Gateway you can achieve end to end SSL and you can create multiple HTTP Settings with different SSL port to achieve this without ILB.
If that is the case you will not get the High Availability as you only have one VM for each SSL port.
Can you explain why you need to use different SSL port for each Machine? Are you hosting multiple Site?
If yes, you can easily achieve with Application Gateway. Please let me know your entire setup and if you have any follow up questions. I am here to help you.
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 :(
I'd like to setup the below infrastructure in Azure. I have one possible solution, but it seems like it makes compromises in security architecture. Is there a better way to do this in Azure than in my compromised workaround?:
VM #1: Role: SQL Server and IIS. Server should have a unique public IP address. The hosted websites will be available through public port 80, and connect to local SQL Server.
VM #2: Role: IIS. Server should have a unique public IP address. The hosted websites will be available through public port 80, and will connect to SQL Server on VM #1.
This has been my experience so far:
No issues setting up VM #1.
With VM #2, I tried building it in the same cloud service as VM #1. When I did that, it was assigned the same public IP address as VM #1. Thus, in this scenario, hosting websites on port 80 on both machines doesn't work.
Next I tried building VM #2 in a different cloud service. This resulted in assignment of a unique public IP address. However, I was unable to obtain connectivity to SQL Server on VM #1.
Things I tried for the above: VM #1 SQL Server set as mixed mode, named SQL account provisioned (and connectivity confirmed locally), SQL configured to allow incoming remote TCP connections, firewall rule opened for incoming connections on TCP port that SQL runs under, but so far have not been able to connect to it from VM #2.
One architecture I believe would work is to open a public port on VM #1 and map that to the private SQL Server port. Then VM #2 could connect using the fully-qualifed public DNS name of VM #1. I believe Azure also would allow connectivity to be constrained to the public IP address of VM #2.
However, this seems less than ideal, because now SQL communication is being routed through a more public route than one would normally design for a data center, and an extra public port has to be opened on VM #1 (even if constrained by IP address, I'd rather not expose that surface area if not necessary). Additionally, sending the SQL Server data over a more public network hypothetically means transport security may need to be considered.
Research indicates connectivity between 2 VMs on different cloud services may not be possible using private ports, although the info I've found so far is not conclusive. So again, is there a better way to do this in Azure?
A single cloud service is a security boundary and the only way into it is through a public (input) endpoint on the unique public VIP of the service. A Virtual Network (VNET) can be used to host multiple cloud services and allow private visibility among them without going through a public endpoint.
A typical model would be to put an IIS website in a PaaS cloud service with a public VIP and the backend SQL Server in an IaaS cloud service with a public VIP but NO public endpoints declared on it. Both these cloud services would be hosted in the same VNET. This allows the front end web role instances access to the backend SQL Server instance over the private VNET. There is a hands-on lab in the Windows Azure Training Kit that describes precisely how to implement this.
In this case I would recommend separating the IIS/SQL Server combination so that the SQL Server box is in an IaaS cloud service with no public endpoint (although it will always have a public VIP). I would also recommend using either a Point-to-Site or Site-to-Site VPN which would allow you to access the VMs without exposing a public RDP endpoint. A point-to-site VPN is developer focused and very easy to configure. A site-to-site VPN is more of an IT thing since it requires configuration of a VPN router such as Cisco, Juniper or Windows Server.
My Azure web role can, using remote desktop, connect with a browser (IE) to google.com and to a DMZ server on our corporate network.
My web role cannot connect via HTTP GET (IE) to a non-DMZ box behind the firewall. My web role cannot ping this box either. My service is hosted in north/central, allegedly all published IP ranges of north/central have been granted access to the target IP by our CorpIT people. They claim they are seeing no traffic via their sniffer from my compute instance IP when I attempt to ping or HTTP GET against the target local IP.
CorpIT wants help from the Microsoft side but we have no Microsoft relationship. I'm convinced this is the outcome of months of slapdash thirdhand firewall rules applied to the target environment in question. What can I do to further elucidate this for CorpIT?
thx in advance!
You can try to run a trace route or get a network trace from the Azure instance and see what you get back from where. You could also create a support case with microsoft:
https://support.microsoft.com/oas/default.aspx?&c1=501&gprid=14928&&st=1&wfxredirect=1&sd=gn
I wouldn't bet on using the IP ranges to make your applications work correctly. Windows Azure already provides you with some services that allow you to solve these types of issues:
Windows Azure Connect: Allows you to create an IPSec secured connection between your servers and your hosted services. This means you won't need to add rules to the firewall for incoming traffic.
Windows Azure Service Bus Relay: Allows you to expose WCF services to the cloud without having to add rules to the firewall for incoming traffic. Choosing this option might add some extra work for you to do, you might need to create a WCF service if you don't already have one and change the code in your Web Role to connect to this WCF Service.
We have a existing application to be migrated to the windows azure.
Currently, it will access another web services in other network, and the firewall in front of the web service, it will trust the IP of it and open the port only for that application.
Which IP should I trust after migrated to Windows Azure? or other approach suggested?
Thanks a lot.
Currently Windows Azure does not offer a fixed IP address, so any IP based filter would be subject to potential risk if the IP address should change (which it can without notice).
I would recommend you explore either leveraging the service bus to create a peer-to-peer connection between the services, or possibly Azure Connect (an ipsec based VPN style connection).