Unable to browse cloud service publicly

Satish Kumar 0

I have recently started facing this issue, what was working just stopped without reason. I have a web-role in cloud service (extended support) which was working fine, now i cannot even browse it publicly.

I can RDP and check the IIS, and browse the same from the rdp server itself, both by ip address and public domain name as well, but from my system, i cannot browse it publicly. Says site cannot be reached error. https://rmidserverstgex.northeurope.cloudapp.azure.com/

What am i missing? I have tried re-publishing the same, no use. The same was working for over a year.

vipullag-MSFT 24,871 Reputation points

2023-11-16T05:57:56.77+00:00

Hello Satish Kumar

Welcome to Microsoft Q&A Platform, thanks for posting your query here.

Can you please check on the networking components of the deployment. Reason could be NSG rule may have been auto - applied per policy and that rule may disallow any public access.

Hope this helps.
Satish Kumar 0 Reputation points

2023-11-16T06:13:21.2066667+00:00

Thanks for the reply, could you kindly point me where i should look for the NSG rules?

For the cloud-service, I have configured the Virtual Network, Subnet, Public IP address and Load Balancer, all seemed to be working fine for a year now.

Note: i'm able to browser by rdp'ing to the IIS itself (located in north Europe region), both by ip address and domain address.
Satish Kumar 0 Reputation points

2023-11-16T06:30:22.54+00:00

I see the option to select an NSG under the SubNet. Right now i dont have any to select from the drop-down, so do i have to create an NSG and add a new rule to allow public access to port 80/443?

Just a question, how was it all working fine up until now and why it could stop suddenly any idea? I have another setup under another subscription, which is exactly similar and still working without any explicit NSG rules set, so I'm curious and worried.
Satish Kumar 0 Reputation points

2023-11-16T07:08:01.8266667+00:00

I have now configured the NSG and associated it with the subnet in which my could-services is running and added rules to allow inbound traffic on port 80, 443 and rdp, but no effect. Only thing that did affect is i can no longer RDP my VM, even after adding rule to allow rdp. Any suggestions?
vipullag-MSFT 24,871 Reputation points

2023-11-16T10:09:34.5766667+00:00

How is the rdp done? Are you using the internal Jit based rdp?
Satish Kumar 0 Reputation points

2023-11-16T10:29:03.1266667+00:00

Thanks for the reply

I'm rdp'ing using the rdp profile that's available on the web-role instance. Just FYI, i didn't have any NSG rules set in my subscription. Everything worked as expected until today when the web-role wasn't being able to browse publicly, so i assume no default rules were being applied. In anyway followed your suggestion and added a NSG and configured inbound rules to allow 80,443 and associated it with the Subnet of the web-role. But that didn't have any impact. On the other hand, the RDP stopped working, so i tried adding NSG rule to allow RDP on port 3389, but that didn't have any impact as well. I just removed the NSG and dis-associated the web-roles Subnet from it and i can RDP again, but still cannot publicly browse the web-role. I can browse on the VM itself to confirm app is fine, and is able to browse with it's DNS address.

Is there any other place to look for what's blocking public access which was all ok up until today? Nothing changed from our side.

1 answer

vipullag-MSFT 24,871 Reputation points

2023-11-17T08:03:19.77+00:00

Hello Satish Kumar

Thanks for providing more details.
Based on all the details provided, tcp ping is working on port 443 which means that the LB is directing traffic to it and the backend is responding. However, Port 80 is not responding, so can you check whether the backend role is listening on port 80?
Please check whether your Vnet has an network manager policies configured which can interfere with port 80\443\3389.
Please sign in to rate this answer.
Satish Kumar 0 Reputation points

2023-11-17T17:40:27.19+00:00

Hi, thanks for the reply.

The web-role acts as an identity-provider, so we just have 443 port enabled which has been sufficient. I have checked the Network Manager and there are no policies configured. As this was ciritcal to have it up and running, i had to re-publish the cloud-service (ex) under a new vNet and it's now accessible publicly. But I still cannot get my head around this issue, something surely is blocking, but we don't have anything set that way.

The things i notably changed this time were

we were using self-signed cert for the web-role (as this is a testing environment, it was ok with a self-signed cert generated using makecert tool), this time i generated the self-signed cert from azure key-vault itself.

I created the solution in vs2022 with the clou service (extended-spupport) template, unlike previously which was older classic cloud-service solution, which i have been publishing using the Publish (extended support) option.

I don't suppose any of these have a significant impact, but just letting you know.

I'd still like to understand the reason why the cloud-services under the old Vnet suddenly were not publicly accessible, while they could be pinged.

Regards

Satish

vipullag-MSFT 24,871 Reputation points

2023-11-20T04:19:33.0633333+00:00

Hello Satish Kumar
Thanks for responding and sharing more all these details.
Just curious to check if your issue is resolved now (are you unblocked now)?

Satish Kumar 0 Reputation points

2023-11-20T06:27:28.5133333+00:00

No, the issue remains, and have raised a tech-support ticket, as I still need to understand why this could occur. I have a similar setup in production (with valid ssl certs), therefore it's critical to understand. The thing is, as this is Cloud-service, I was never required to manage or configure any n/w related policies. Even after migrating to Cloud-service extended support, I only had to set up the Vnet & Subnet with no policies and the public-ip's were just fine for over a year now, until this happened. 2 of my cloud-services (extended support) apps in the same Vnet were affected. Adding NSG resource and configuring inbound policies allowing port 80 and 443 didn't have any impact - which was surprising. Leaving me with no option but to publish these services under a new Vnet & Subnets for both, which immediately worked just as expected with public ips's browsable. Like I mentioned, the only notable change I did was generating self-signed certs from Key vault instead of makecert tool and a new Vnet and Subnets.

Could there be a higher-level blocking somewhere else?

Any relation to self-signed certs and DNS servers blacklisting them?

While port-ping worked, still they were not publicly browsable, any possible reasons?

Regards

Satish

vipullag-MSFT 24,871 Reputation points

2023-11-21T04:10:24.87+00:00

Hello Satish Kumar
Thanks for responding, can you please share the support case details.

Satish Kumar 0 Reputation points

2023-11-21T06:08:32.38+00:00

Sure, please find it below

Unable to browse web-role publicly - TrackingID#2311160030004691

Regards

Satish

vipullag-MSFT 24,871 Reputation points

2023-11-21T07:05:38.57+00:00

Hello Satish Kumar
Can you please also elaborate what browsable means in this context? What is it that is not working? Can you RDP and locally "browse"?

Satish Kumar 0 Reputation points

2023-11-21T07:08:52.4866667+00:00

Yes I can RDP to the web-instance and browse it locally, both by ip address and domain name. But when i browse the site normally from browser over internet, then the site cannot be reached.

vipullag-MSFT 24,871 Reputation points

2023-12-06T03:44:01.3+00:00

Hello Satish Kumar

As you have support case filed, this will be investigated and resolved by support team.
Once the issue is resolved, request you to post the resolution here for the benefit of community.
Sign in to comment

Share via

Unable to browse cloud service publicly

1 answer