link update

Author: seligj95

articles/app-service/environment/app-service-app-service-environment-control-inbound-traffic.md

@@ -15,14 +15,15 @@ ms.author: madsd
 >
 > As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.
 >
-> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios. 
+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.
 >
-> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-ase-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.
+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.
 >
 > For the most up-to-date information on the App Service Environment v1/v2 retirement, see the [App Service Environment v1 and v2 retirement update](https://github.com/Azure/app-service-announcements/issues/469).
 >
 
 ## Overview
+
 An App Service Environment can be created in **either** an Azure Resource Manager virtual network, **or** a classic deployment model [virtual network][virtualnetwork].  A new virtual network and new subnet can be defined at the time an App Service Environment is created. Instead, an App Service Environment can be created in a preexisting virtual network and preexisting subnet.  As of June 2016, ASEs can also be deployed into virtual networks that use either public address ranges or RFC1918 address spaces (private addresses).  For more information, see [How to Create an ASEv1 from template](app-service-app-service-environment-create-ilb-ase-resourcemanager.md).
 
 Always create an App Service Environment within a subnet. A subnet provides a network boundary that can be used to lock down inbound traffic behind upstream devices and services. This setup allows only specific upstream IP addresses to accept HTTP and HTTPS traffic.
@@ -34,6 +35,7 @@ Once you assign a network security group to a subnet, inbound traffic to apps in
 [!INCLUDE [app-service-web-to-api-and-mobile](../../../includes/app-service-web-to-api-and-mobile.md)]
 
 ## Inbound Network Ports Used in an App Service Environment
+
 Before you lock down inbound network traffic with a network security group, know the set of required and optional network ports used by an App Service Environment.  Accidentally closing off traffic to some ports can result in loss of functionality in an App Service Environment.
 
 The following list contains the ports used by an App Service Environment. All ports are **TCP**, unless otherwise clearly noted:
@@ -53,13 +55,15 @@ The following list contains the ports used by an App Service Environment. All po
 * 4026: Used for remote debugging with Visual Studio 2022.  This port can be safely blocked if the feature isn't being used.  On an ILB-enabled ASE, this port is bound to the ILB address of the ASE.
 
 ## Outbound Connectivity and DNS Requirements
+
 For an App Service Environment to function properly, it also requires outbound access to various endpoints. A full list of the external endpoints used by an ASE is in the "Required Network Connectivity" section of the [Network Configuration for ExpressRoute](app-service-app-service-environment-network-configuration-expressroute.md#required-network-connectivity) article.
 
 App Service Environments require a valid DNS infrastructure configured for the virtual network.  If the DNS configuration is changed after the creation of an App Service Environment, developers can force an App Service Environment to pick up the new DNS configuration.  If you trigger a rolling environment reboot using the **Restart** icon, the environment picks up the new DNS configuration. (The **Restart** icon is located at the top of the App Service Environment management page, in the [Azure portal](https://portal.azure.com).)
 
 It's also recommended that any custom DNS servers on the virtual network be set up ahead of time before creating an App Service Environment.  If a virtual network's DNS configuration is changed during the creation of an App Service Environment, the App Service Environment creation process fails.  Similarly, if there's a custom DNS server that's unreachable or unavailable on the other end of a VPN gateway, the App Service Environment creation process will also fail.
 
 ## Creating a Network Security Group
+
 For full details on how network security groups work see the following [information][NetworkSecurityGroups].  The Azure Service Management example below touches on highlights of network security groups. The example configures and applies a network security group to a subnet that contains an App Service Environment.
 
 **Note:** Network security groups can be configured graphically using the [Azure portal](https://portal.azure.com) or through Azure PowerShell.
@@ -89,7 +93,7 @@ Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityR
 Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT HTTPS" -Type Inbound -Priority 300 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP
 ```
 
-If FTP support is wanted, use the following rules as a template to grant access to the FTP control port and data channel ports.  Since FTP is a stateful protocol, you might be unable to route FTP traffic through a traditional HTTP/HTTPS firewall or proxy device.  In this case, you need to set the *SourceAddressPrefix* to a different value, such as the IP address range of developer or deployment machines on which FTP clients are running. 
+If FTP support is wanted, use the following rules as a template to grant access to the FTP control port and data channel ports.  Since FTP is a stateful protocol, you might be unable to route FTP traffic through a traditional HTTP/HTTPS firewall or proxy device.  In this case, you need to set the *SourceAddressPrefix* to a different value, such as the IP address range of developer or deployment machines on which FTP clients are running.
 
 ```azurepowershell-interactive
 Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT FTPCtrl" -Type Inbound -Priority 400 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '21' -Protocol TCP
@@ -107,6 +111,7 @@ Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityR
 ```
 
 ## Assigning a Network Security Group to a Subnet
+
 A network security group has a default security rule that denies access to all external traffic. When you combine this rule with the network security rules above, only traffic from source address ranges that are associated with an *Allow* action will be able to send traffic to apps that run in an App Service Environment.
 
 After a network security group is populated with security rules, assign it to the subnet containing the App Service Environment.  The assignment command references two names: the name of the virtual network where the App Service Environment is, and the name of the subnet where the App Service Environment was created.  
@@ -126,13 +131,15 @@ Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Remove-AzureNetworkSecuri
 ```
 
 ## Special Considerations for Explicit IP-SSL
+
 If an app is configured with an explicit IP-SSL address (applicable *only* to ASEs that have a public VIP), instead of using the default IP address of the App Service Environment, both HTTP, and HTTPS traffic flows into the subnet over ports other than ports 80 and 443.
 
 To find the individual pair of ports that is used by each IP-SSL address, go to the portal and view the App Service Environment's details UX blade.  Select **All settings** > **IP addresses**.  The **IP addresses** blade shows a table of all explicitly configured IP-SSL addresses for the App Service Environment. The blade also shows the special port pair that's used to route HTTP and HTTPS traffic associated with each IP-SSL address.  Use this port pair for the DestinationPortRange parameters when configuring rules in a network security group.
 
-When an app on an ASE is configured to use IP-SSL, external customers won't see or need to worry about the special port pair mapping.  Traffic to the apps will flow normally to the configured IP-SSL address.  The translation to the special port pair automatically happens internally, during the routing traffic's final leg into the subnet that contains the ASE. 
+When an app on an ASE is configured to use IP-SSL, external customers won't see or need to worry about the special port pair mapping.  Traffic to the apps will flow normally to the configured IP-SSL address.  The translation to the special port pair automatically happens internally, during the routing traffic's final leg into the subnet that contains the ASE.
 
 ## Getting started
+
 To get started with App Service Environments, see [Introduction to App Service Environment][IntroToAppServiceEnvironment].
 
 For more information, see [Securely connecting to Backend resources from an App Service Environment][SecurelyConnecttoBackend].