![Azure]()
Recently, I got to work with a client on something interesting. We implemented transactional replication to send the data to an Azure virtual machine. This was being done to perform some testing for a project.
Given that the two machines were NOT within the same Active Directory domain, we wanted to make sure our client’s data was protected, so we utilized a Point-to-Site VPN to facilitate this. With the client using a VPN connection, this helps to ensure that any data transmitted to the virtual machine is encrypted and secured. Note, the process on how to configure and implement the VPN connection is for another blog post.
SQL Server replication requires the use of a server name rather than just the IP addresses. This meant that the virtual machine in Azure had to use an entry in the local host file that was pointed back to the client’s machine.
The downside? When the VPN connection drops (it happens), the client machine obtains a new IP address upon reconnecting. Potentially, now the host file would have the incorrect IP address and needs to be updated. Not a difficult task but how do you know what to update it to? You could ask the client; however, asking the client to tell us what the new IP address every time, is... well, irritating. Thankfully, there is a way to determine what the IP address might be from the Azure portal itself!
- Log into the Azure portal VC.
- Go to Virtual Network Gateways.
- Click on the Gateway that is using the VPN.
- Go to “Point-to-site configuration”.
On the subsequent blade, towards the bottom, you’ll see the “Allocated IP Addresses”. Voila!
![Azure]()
If you have multiple connections, it might be more difficult to determine what IP address is for which connection. However, in this case, we only had a single connection so it is easy to determine. This allowed us to easily and quickly update the local host file without having to disturb the client for this information.
However, as easy as it is to determine the IP of the connection, pointing to the site really shouldn’t be used for production. It was used in this case as a Proof of Concept (PoC) for a client. This was the fastest most secure way to connect Azure, even though it’s a bit fragile.
Enjoy!!