Connecting the on-premises environment to Azure will require a VPN device. In this video, Sharon outlines where to find out if you VPN device is validated and provide some options if its not.
- [Narrator] Once you have determined that you are going to connect your Azure implementation to your on-premise environment, you will need to ensure that the device on-premise is a validated VPN device that can be used for Azure. The best place to go for this will be the Azure website itself. And what you will do here is you will actually go through the list of the vendors and see if your device is actually within that list. You'll notice that this list is fairly long. After you pick out your vendor, then you're going to ensure that your device fits within the device family that is supported.
And next you will check for the minimum OS version, and this is critical. You may end up having to update your device itself. Or, if your device cannot be updated, you'll be looking at moving into a new device. And finally, you will have configuration instructions, if they're available for that device, depending if it's policy-based or route-based. You'll notice that this list is quite extensive. Now, it is possible to use a non-validated VPN device, if it supports IPsec IKE.
You may also have to contact your manufacturer for additional support and configuration instructions. My suggestion: if you are going to use a non-validated VPN device, set it up in a test environment first. Work out all the bugs and the kinks before you pop it into production. One thing I want to point out here is you'll notice that we actually have Microsoft within this list. If you do not have a VPN device that fits into this list, you can use Microsoft's Routing and Remote Access Service within Windows Server 2012.
I usually recommend setting up the Routing and Remote Access Service on-premise for a test environment first, before configuring the VPN router itself. That way, you can work out all the bugs, understand exactly how the service is going to connect, you can test for bandwidth and throughput from on-premise to Azure. You can have your users actually test that connection for you as well. One of the things that I found when I was working with Microsoft partners, when we would go ahead and connect the on-premise to Azure, that connection would be great.
The problem would be in the back end. And there would be a huge lag in the office itself. And most of the time, this was related to the infrastructure in-house. So before jumping out and connecting all of your services, spend some time, inventory what you have on-premise, because that on-premise networking, excuse the pun here, it must also be up to speed. If you have old switches in place, then you may find the performance not acceptable. And that's one of the reasons why I do suggest, before jumping right in with both feet, is actually configure the Microsoft server for testing.
Find those bugs, find those hiccups. You want to ensure that a implementation is successful, not only in Azure, but on-premise as well. And one last tip of the trade: You will be making configuration changes to your router. I would highly, highly recommend that you back up your current configuration on that router, just in case things do not go as planned.
- Creating an Azure virtual network
- Creating a virtual network using PowerShell
- Deploying a VM into a virtual network
- Modifying IP addresses
- Working with Azure DNS
- Configuring NSGs
- Setting up load balancers
- Configuring Azure load balancers
- Creating an application gateway
- Setting up on-premises connectivity
- Adding gateway VPNs
- Validating VPN devices
- Configuring VNet
- Creating site connections