Merge pull request #242368 from ntrogh/als-networking-scenarios-fix

[Azure Lab Services] Remove workaround for additional ports

Author: prmerger-automator[bot]

articles/lab-services/concept-lab-services-supported-networking-scenarios.md

@@ -21,7 +21,7 @@ The following table lists common networking scenarios and topologies and their s
 | Scenario | Enabled | Details |
 | -------- | ------- | ------- |
 |  Lab-to-lab communication | Yes  | Learn more about [setting up lab-to-lab communication](./tutorial-create-lab-with-advanced-networking.md). If lab users need multiple virtual machines, you can [configure nested virtualization](./concept-nested-virtualization-template-vm.md). |
-| Open additional ports to the lab VM | No | You can't open additional ports on the lab VM, even with advanced networking.<br/><br/>A workaround solution is to use PowerShell or the Azure SDK to manually add the NAT rules for every VM in the lab (every private IP address). This solution isn't recommended because of the limit on the number of allowed rules for load balancers, and because it's unclear to lab users what the port number for their lab VM is. |
+| Open additional ports to the lab VM | No | You can't open additional ports on the lab VM, even with advanced networking. |
 | Enable distant license server, such as on-premises, cross-region | Yes | Add a [user defined route (UDR)](/azure/virtual-network/virtual-networks-udr-overview) that points to the license server.<br/><br/>If the lab software requires connecting to the license server by its name instead of the IP address, you need to [configure a customer-provided DNS server](/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances?tabs=redhat#name-resolution-that-uses-your-own-dns-server) or add an entry to the `hosts` file in the lab template.<br/><br/>If multiple services need access to the license server, using them from multiple regions, or if the license server is part of other infrastructure, you can use the [hub-and-spoke Azure networking best practice](/azure/cloud-adoption-framework/ready/azure-best-practices/hub-spoke-network-topology). |
 | Access to on-premises resources, such as a license server  | Yes | You can access on-premises resources with these options: <br/>- Configure [Azure ExpressRoute](/azure/expressroute/expressroute-introduction) or create a [site-to-site VPN connection](/azure/vpn-gateway/tutorial-site-to-site-portal) (bridge the networks).<br/>- Add a public IP to your on-premises server with a firewall that only allows incoming connections from Azure Lab Services.<br/><br/>In addition, to reach the on-premises resources from the lab VMs, add a [user defined route (UDR)](/azure/virtual-network/virtual-networks-udr-overview). |
 | Use a [hub-and-spoke networking model](/azure/cloud-adoption-framework/ready/azure-best-practices/hub-spoke-network-topology) | Yes | This scenario works as expected with lab plans and advanced networking. <br/><br/>A number of configuration changes aren't supported with Azure Lab Services, such as adding a default route on a route table. Learn about the [unsupported virtual network configuration changes](./how-to-connect-vnet-injection.md#4-optional-update-the-networking-configuration-settings). |