When setting up an Application Gateway (AGW), the public and private IP addresses of the Application Gateway are required in order to complete the configuration. The Application Gateway needs 24 hours before new DNS and network settings are taken into account. Or you can trigger this part of the process by manually stopping and starting the Application Gateway.
1) Manually triggering a restart of the Application Gateway
To provide you some context, an Application Gateway in the Microsoft datacenter is a Virtual Machine spin up with (Layer 7) software that functions as a Load balancer and (if configured) detects and stops malicious requests.
To manually stop and start the AGW via PowerShell, you can use the following commands:
$agw = Get-AzApplicationGateway -Name <name of AGW> -ResourceGroupName <resource group here>
Stop-AzApplicationGateway -ApplicationGateway $agw
// or
Start-AzApplicationGateway -ApplicationGateway $agw
2) Failed to start Application Gateway services
When restarting the Application Gateway, we encountered an error.
This error can be found in the Activity Log section in the left navigation section of the Azure resource.
The JSON representation of the error was the following:
This error message is not very helpful as little or no information is given about the reason you cannot start the AGW service.
There are a few hits on Google which are helpful, but after performing some research, I found the root cause. Our architecture includes routing tables to forward network traffic to the Firewall servers. If a routing table is associated with the subnet in which the Application Gateway is configured, it will return an error on startup
3) Solution
- First, remove the association between the routing table and the subnet;
- Start the Application Gateway (it will start without any problems);
- Reassociate the routing table to the VNET, then wait 24 hours for the routing table to work correctly in the Application Gateway service.