Azure: Accessing Private Resources
This page provides a step-by-step guide to setting up Twingate to access private Resources in Azure.
Let’s take a simple example Azure tenant, with one virtual network, a VM running an SSH server, and a VM running an HTTP server. None of the servers have public IP addresses, so they aren’t accessible over the Internet.
First, we need to deploy a Connector. To do this, we need to create a new subnet inside of Azure, because our Connector runs as a Container instance, and in Azure, Containers cannot be in the same subnet as VMs or anything else besides other Containers.
1. Now that you’ve prepared your network to deploy the Connector, go to the Twingate Admin Console and add a new Remote Network.
2. Once the network is created, go to the Remote Network’s page and add a new Connector, then select Deploy Connector.
Then click Deploy Connector to start the deployment process.
If both Controller and Relay status are not shown as green, please follow the troubleshooting instructions in the deployment workflow screen.
Next, we’ll create some example Resources for our two servers and connect to them.
Note that we didn’t need to specifically configure the zone in Twingate; so long as it is defined for the Connector, names will resolve successfully.
You can also use the internal IP of a VM to define a Resource, but note that users will only be able to access the Resource using the defined address, whether IP, DNS, or both.
Connect to Twingate using the Twingate Client. Once connected, you should see the Resources appear in the client application’s tray menu (Windows or macOS), within the app itself (Android, iOS, ChromeOS), or via the command line for Linux.
SSHing into our internal IP now works.
Accessing the HTTP server using its internal domain also works.
While this was a simple example, the same concepts can be applied to deploying more complex applications inside of Azure, or in a hybrid deployment if some Resources are on premises.
Last updated 3 minutes ago