Azure App Service doesn't see Worker Roles in VNET

0
votes

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)

2
azureazure-virtual-networkorleans
Maybe this document Integrate your app with an Azure Virtual Networkcan help. – Charles Xu
I had read that, I do not see anything I'm doing that's inconsistent to it. – tec-goblin
Can you allow the port 30000, 11111 in your NSG inbound rule? – Nancy Xiong
Could you describe "The App Service is assigned to this VPN ("Certificates in sync") " in your question? Does your app integrate with another Vnet? It Seems that you have Azure VNET (Classic) integrated with Worker Role? – Nancy Xiong
I mean that in the networking page of the App Service options I assigned this app to this Classic VNET. I also assigned to Subnet-1 the Worker Role and the NSG. I also allowed these two ports now (inbound), after your suggestion, and restarted the Worker Role. Still getting the same error. – tec-goblin

2 Answers

1
votes

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

0
votes

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.