I am running a container instance in a private network as self-hosted agent to perform DevOps pipeline jobs. The container instance resides in vnet-a and all traffic to the internet is routed via a firewall instance in vnet-b:
If I start the container instance, it displays the logging [1;36m1. Determining matching Azure Pipelines agent...[0m. This indicates that it can't connect to the Azure DevOps server.
On the container instance, I opened outbound TCP ports 443 and 80. Furthermore, I created outbound rules on the firewall that allows traffic over port 443 from the container instance IP towards the four DevOps IP adresses.
The problem is fixed. When the subscriptions where requested at another department, the guy forgot to say that the environment must be able to talk to internet and therefore, NAT rule was not in place. Problem solved.
Related
I am running Azure DevOps Ubuntu self-hosted agent as container in the Container Instances. What are the minimum inbound and outbound network traffic rules so the agent can operate? I tried ports 80 and 443 TCP for both in and outbound but the container is still not able to find the DevOps Agent pool (it says [1;36m1. Determining matching Azure Pipelines agent...[0m).
As depicted here, only outbound HTTP(S) on port 443 is required.
What can I do to fix this Advisory message?
The VM this relates to is a webserver, which sits behind an Azure LoadBalancer. The NSG rule that is causing this (only 1 'not default rule' ) is:
Type: Allow
Source: Service Tag - Internet, source port range = *
Destination: ASG for this VM, destination port 80,443, protocol tcp
If I remove this rule, the message disappears (after some hours) but than the internet web traffic can not reach the VM anymore.
Should I ignore the Azure Advisory message? Or am I overlooking something? I was looking forward to getting this nice and tidy, AND have a 'satisfied' advisory state.
You can run your webserver on the VMs on different ports than 80 and 443. The load balancer can translate between port 80/443 on your public IP and whatever port you choose inside the VMs. Since Load Balancers are a fairly simple service, this is probably your only option.
As an alternative, you could try Application Gateway instead of your load balancer. It should act as the reverse proxy you need. Be aware that it is a bit more costly than the load balancer, but it also has a lot more features.
I see that your VM is behind an Azure LoadBalancer. So, the network flow might be similar to :
Then, your web server should not be public to the internet. It should only be accessible from the loadbalancer. You can set the source service tag to AzureLoadBalancer. For more information about service tags, you may check the official documentation: Service tags
Update:
By further researching, the AzureLoadBalancer service tag in NSG rule is used to allow Azure health probes. Actually, there is a default rule for allowing load balancer to probe to endpoints.
So, the suggestions are:
You should not assign public IPs to each instances. In this way, your backends can only be accessed by private IPs. In other words, clients can only access your web via load banlacer.
Add NSG inbound rules with 80 and 443 ports for web service. And 22 or 3389 port for remote management.
In this case, your servers should be secure now. If there are still any warnings, I think you may ignore them. The Azure system may just see that you opened 80 and 443 ports to public. However, your instances do not have public IP.
Hope the above would be helpful to you.
I need to configure an Orleans cluster to connect to an Azure App Service. The issue is that networking is my weakest point ;).
I have configured an Orleans Silo using Azure Worker Role (4 instances), listening to the default ports:
.ConfigureEndpoints(siloPort: 11111, gatewayPort: 30000)
I've assigned the Worker Role to an Azure VNET (Classic) with these settings:
Address Range 10.0.0.0/24
Subnet-1 10.0.0.0/27 (the Worker Role is Assigned here as part of a network security group)
Point to Site range 10.0.1.0/24
GatewaySubnet 10.0.0.32/29 (added to the same network security group)
I see that the 4 instances take proper IPs in the Subnet-1: 10.0.0.4 to 10.0.0.7.
The App Service is assigned to this VPN ("Certificates in sync") and reports:
IP ADDRESSES ROUTED TO VNET
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
I see that the app service tries to connect to 10.0.0.7:30000
I tested both by checking application diagnostics and by using tcpping that 10.0.0.7:30000 is not accessible by the application. (Could not connect to 10.0.0.7:30000: AccessDenied)
I am definitely missing something elementary here, I haven't configured IPs in a decade!
(This is similar to Vnet between Virtual Machine and App Service in Azure but in this case I do want to configure the VNet, and I have a specific practical issue)
For the networking, I suggest verifying the following things:
You have integrated your app into a Classic VNET, and enable Point to Site in a Classic VNet as this DOC.
Confirm if the desired port in Orleans cluster is listening. You can go through this website to troubleshoot on the Orleans cluster side.
Firewall (VM or host lever) and NSG rules to allow the desired ports. Get more details from this.
For more references, Create a VNET and access an Azure VM hosted within it from an App Services Web App
After checking in detail all the documents Nancy provided, I ended up connecting through VM to one of the cloud service VMs (the silo). I needed to allow it through the NSG. I checked with netstat -aon that the service was listening to the expected ports. I could ping the other instances of the service.
Then I downloaded tcping and tried to connect to the expected ports from that instance to the others. It was blocked. As I was within the same silo, I could now pinpoint the problem to "Firewall (VM or host level)" (one of the possible issues Nancy mentioned).
The solution was to configure the Endpoints at the Cloud Service definition (csdef), thus the VM firewall was blocking access to these ports. I naively thought that it was enough to configure them at the SiloBuilder level, but SiloBuilder is application layer, it doesn't update the VM it's running on.
The result is that now netstat -aon was showing the service connections to 11111 as "established" not just "listening" and the VM's firewall was showing the new rules. The worker role instances could connect to each other.
Still the app service (web app) couldn't connect to the host:port of any of the worker roles. I tried to remove the NSG but this caused the instances not to be able to see each other again, so I reassigned the NSG to subnet-1 and the GatewaySubnet.
The final thing I tried was to disconnect the App Service from the VNET and re-connect it. I've run on other (unrelated) errors at that step, I will update the post when I sort them out.
I want to open a port on Azure. I am logged onto Azure VM. After that how to do I open the port?
I tried opening the firewall port but that did not help. I also tried to do it thru azure-cli but it needs web login.
Can I not open a port while logged in onto that Azure VM?
For VMs in azure service management mode:
To open a particular port, say 8080 in your VM, you have to add an endpoint in azure portal, powershell or using xplat-cli. Once this is done, you have created a connectivity between external loadbalancer (I mean VIP of the VM) to the actual VM (with Internal IP address). If the VM is Linux, by default you can start using endpoint (VIP and port) it unless you restrict ports specifically.
For windows VM, for non standard ports, you have to add windows firewall inbound allow rules (say for 8080) inside your VM so that it can accept traffic forwarded from VIP
For VMs in azure resource management:
You have to first create a loadbalancer with VIP, then add NAT rules to forward traffic from VIP to VM. (use load balancing rules if same VIP port forwards traffic to multiple backend VMs)
For windows VM, again windows firewall inbound rules needs to be added
Securing ports:
The above scenario will work by default, but if you want to secure your ports, you have to follow either one of the below, not both.
Use Access control List (ACL): This works at VIP endpoint level. If we want to restrict VIP port 8080 to only few Ip and deny other IP, we can use ACL to add those IPs. This can be done in portal endpoint section/powershell/Xplat-cli
Use Network Security Group (NSG): This works at pheriphery of VM level. We have greater control here to restrict multiple VM ports, port range, etc., but we have to manage those rules. The ports needs to be secured in NSG is the VM internal port whereas in ACL it is the VIP port.
Hope this clarifies
You also need to open the port in the Endpoint settings within the Azure Portal.
Go to Azure Portal -> Your VM -> Settings -> Endpoints and add your Port.
To open a port, you have to it from the azure portal and not in the VM. You can use the NSG (Network Security Group) attached to vm and add a rule in the "Inbound security rules"
I'm trying to build a simple two-tier wordpress environment on CentOS 7.2 in Azure.
I've defined a virtual network, have connected it to my home-lab via IPsec VPN, and I've defined several subnets in Azure (for Web tier, SQL tier, and utility tier role segregation using Network Security Groups).
I have two web-tier VMs, both members of the same Availability Set, and are both on the web-tier subnet. They have internet access (outbound), I can SSH to them from my home-lab, and the seem fine operationally to me - httpd is listening on 80/tcp, and I can hit the web pages from my home-lab network by visiting each web server directly on its 192.168.x address.
I should mention my web servers DO NOT have public IPs assigned, but I can't see this being an issue.. they're intended to be behind the load balancer.
So, I've created a Load Balancer, and:
assigned a public IP to the LB
added a backend pool (selected my availability set, and chose my two web servers)
added a probe (http probing the two web servers)
added a load balancer rule
Notice I did NOT add an inbound NAT rule. I can't figure out what that's for, or if I need it.
On my web tier, I tcpdump port 80 and see the probes. In httpd logs, I see 200 success messages for the probes. I go to a web browser, hit the external VIP I assigned to the LB, and nothing. It just times out. I cannot connect to the LB VIP.
What am I missing? What are the NAT rules about?
Any help would be appreciated. All I can find online are examples doing this in powershell etc.. and I'm using the Azure web interface.
Thanks!
Edit: Found the issue - Needed the NSG to allow not just the AzureLoadBalancer, but "Internet" to hit port 80/tcp. Should have thought of that sooner..
Found the issue - Needed the NSG to allow not just the AzureLoadBalancer, but "Internet" to hit port 80/tcp. Should have thought of that sooner..