Azure-docs: Poor rule description. Lacks information.

[ducatikiller]

This is a poor rule description. Simple technical writing trumps anything fancy. From Network A to Network B - TCP Port * would enable this article to be empowering. Links to this article on forums leave people mystified. I am frustrated. In the 'Apply NSGs to AzureBastionSubnet' I followed rule creation that will not allow my to apply the NSG to the AzureBastionSubnet. I've been configuring firewalls for over 20 years and this simple act has me unusually furious. Make FROM TO statements. Make it simple. Don't assume. This article is quite terrible. Additionally, the quickstart template is useless. There are NO rulesets. C'mon guys. Really?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: cc46ceac-e45e-6f29-dd5b-6453c614d9b2
• Version Independent ID: b8b3bb83-5204-1f8b-787f-eb3da444e22e
• Content: Working with VMs and NSGs in Azure Bastion
• Content Source: articles/bastion/bastion-nsg.md
• Service: bastion
• GitHub Login: @cherylmc
• Microsoft Alias: cherylmc

[AjayKumar-MSFT]

@ducatikiller, We apologize for the frustration that you encountered following this document.
Thanks for the feedback! I have assigned the issue to the content author to review further and update the document as appropriate.

[msrini-MSFT]

@ducatikiller , Are you getting any error while applying NSG?

Can you share me the screenshot of your NSG so that I can take a look?

[ducatikiller]

@msrini-MSFT, Yes, it wouldn't allow association with the Bastion subnet due to misconfiguration of the NSG. The article above keeps mentioning the 'control plane'. There is no definition of the 'control plane', there is no TAG for the 'control plane'. The article repeats itself trying to state the same thing twice but the nomenclature is not mirrored. Firewall instructions can be very simple. Source/Destination:Port. A simple three column table. Clear and simple. As engineers or psuedo engineers we tend to be 'very smart' and explain things in 'very smart' ways. Simplicity is the path to empowerment. Complexity kills us while we try and read the directions on how to get on how to pull the parachute rip cord.

[msrini-MSFT]

@ducatikiller, Thank you for your feedback. Can you check this issue : https://github.com/MicrosoftDocs/azure-docs/issues/42737

Below is the screenshot of the NSG configuration:

Any management operation that you do to the resource is control plane and as of today we don't have a tag named Control Plane. So, in this context, the Bastion needs to communicate to other internal component within Azure over certain ports. If you block that communication, it will break the service.

[ducatikiller]

First off, thank you for taking the time. I was able to get the subnet to associate with these non-restrictive rules. Security Center categorizes this rule set as non-restrictive. Regarding the Any Any rules. Is there a way to specify and advertised subnet or individual machine rules for access or do the rules need to be 'wide open' like this? One thing I found interesting about the first inbound rule FROM Gateway Manager TO Any with 443, I've parsed the article and would not have derived that. The recommendation states "Control plane connectivity: Inbound on 443 from GatewayManager" This is misleading. I created FROM Gateway Manager TO 'Bastion Subnet'. THEN, I also create a FROM Any TO Gateway Manager Port 443 rule thinking this was necessary for 443 inbound public to get TO the Gateway Manager. If you re-read the article it seems to imply that. Again, thank you for taking the time. Suggestion for article clarity and the most 'locked down' rule set, it would be nice to provide the 'minimum access necessary' in order to make the NSG functional. ANY ANY rule sets tend to make most network people very,very nervous. Thank you for assisting on getting the NSG to allow saving. An extremely restrictive version of the ruleset for the article would be greatly appreciated. Again, thank you.

[msrini-MSFT]

@cherylmc , Can you update the doc to provide more clarity ?

[MisiekBest]

Hi guys.
I think @msrini-MSFT missed one inbound rule (443 from any, not only GatewayManager)
Without it I was unable to connect to any host using Bastion and I found it in azure quickstart examples for Bastion with nsg.
Also there is also an additional port to allow communication (4443 from GM)

Anyway, this configuration works for me perfectly:

[cherylmc]

assign:ashjain

[nicolaibaralmueller]

We can't open up inbound port 443 from any source to any. This violates our security. This needs a service source like any other Azure server! Unable to use this feature unless fixed.

[cherylmc]

assign:charwen

[DYNSOL]

Why does it say "Inbound on 443 from GatewayManager" is required, but the screenshot above and the ARM template has an Any Any rule for 443 which essentially makes the GM rule redundant. Can we be more specific here and have the ability to lock 443 down to GM or similar and get this service to work?

[habnux]

Thanks to @MisiekBest I could set the rules. It would be nice if this would be better documented. It took me a while to find out.

[juanjojulian]

These rules are not acceptable in a corporate environment, too many "from ANY" or "to ANY" statements, security rules should be granular.

[Andy-bridle]

echoing many of the comments above, a more restrictive alternative to the inbound 443 ANY/ANY rule is required

[habnux]

We switched to Azure Bastion for our scale sets. Now the question arises, if we should put the NSG on the Bastion subnet itself at all.
From my point of view, I don't want to define these rules because Azure Bastion is a PaaS and is managed by Microsoft. According to the description it is sold as such:

No hassle of managing NSGs: Azure Bastion is a fully managed platform PaaS service from Azure that is hardened internally to provide you secure RDP/SSH connectivity. You don't need to apply any NSGs on Azure Bastion subnet. Because Azure Bastion connects to your virtual machines over private IP, you can configure your NSGs to allow RDP/SSH from Azure Bastion only. This removes the hassle of managing NSGs each time you need to securely connect to your virtual machines.

Is there a clear usecase when to define these rules yourself? I also think that the documentation in this area is not very clear and could be improved. At least for me :-)