I was working with a customer recently that put a website into Azure Web Apps. This site needed to connect to their backend databases (which they couldn’t move to Azure because legacy systems still needed to connect to it). We created an Azure VNet and configured site-to-site connectivity that created a secure connection between the Azure VNet and their on-premises network.
We then had to configure point-to-site connections for the VNet so that we could put the Azure Web App onto the VNet. This would (in theory) allow the website to access their on-premises resources such as the database. We also had to upgrade the site to Standard pricing in order to do this.
We had to reconfigure the site-to-site gateway to allow dynamic routing in order to do this, which meant deleting and recreating the gateway. A bit of a pain, but not too bad. We then configured static routing from the on-premises network to the point-to-site addresses on the VNet.
Ping from Azure Web App?
Once we had that all configured, we wanted to test connectivity. If we had deployed a VM, it would have been simple – just open a cmd prompt and ping away. However, we didn’t have a server, since we were deploying an Azure Web App. So initially we deployed a dummy Azure Web App onto the VNet to test the connection. This became a little bit of a pain. However, I remembered reading about Kudu and decided to see if that would be easier.
Kudu to the Rescue
If you browse to http://<yoursite>.scm.azurewebsites.net (where <yoursite> is the name of your Azure Web App) then you’ll see the Kudu site.
Once you’ve opened the Kudu site, you can do all sorts of interesting things (see this blog post and this Scott Hanselman and David Ebbo video). If you open the Debug console (you can go CMD or PowerShell) then you get to play! I opened the CMD console and typed “help” – to my surprise I got a list of commands I could run:
Unfortunately I didn’t see anything that would help me with testing connectivity. However, I remembered that I had read somewhere about the command “tpcping”. So I tried it:
Looks promising! Even better than the “ping” command, you can also test for a specific port, not just the ip address. So I want to test if my site can reach my database server on port 1443, no problem:
tcpping 192.168.0.1:1443 <enter>
After troubleshooting for a while, we managed to sort the problem and tcpping gave us a nice “Success” message, so we knew we were good to go. Kudu saved us a lot of time!