Introduction
Together with the
launch of Windows Azure Infrastructure as a Service (IaaS) this summer,
Microsoft also introduced a way for customers to connect their on-premise
networks with Windows Azure using site-to-site VPN.
The service
responsibel for this feature is called Windows Azure Gateway. It uses IPSec to
establish a site-to-site VPN tunnel between your network and your networks in
Windows Azure. Effectively adding a second site to your network. Currently only
Cisco and Juniper devices are officially supported as your local part of the
tunnel. However since Windows Azure Gateway is using standard IPSec
site-to-site tunneling you could theoretically use any device supporting the
requirements. One such scenario using Windows Server 2008 R2 as our on-premise
router, is the purpose of this port. (If you’re wondering why I’m not using
Windows Server 2012, the answer is simply that it does not support the
requirements. Specifically Windows Server 2012 does not do NAT-T like Windows
Server 2008 R2 does.)
Requirements
The Windows Azure
Gateway documentation lists the following requirements for the on-premise VPN
device:
§ VPN device must have a public facing IPv4
address
§ VPN device must support IKEv1
§ Establish IPsec Security Associations in
Tunnel mode
§ VPN device must support NAT-T
§ VPN device must support AES 128-bit encryption
function, SHA-1 hashing function, and Diffie-Hellman Perfect Forward Secrecy in
"Group 2" mode
§ VPN device must fragment packets before
encapsulating with the VPN headers
Fortunately for us
Windows Server 2008 R2 supports all of these! So let’s set it up.
Before you can
configure your local device you have to perform these steps in the Windows
Azure Management Portal:
§ Create one or more virtual networks (WAVN) in
Windows Azure
These will host you Windows Azure VMs and be your LANs in Windows Azure.
These will host you Windows Azure VMs and be your LANs in Windows Azure.
§ Define a local netwok in Windows Azure
Configure this network with all the subnets that you run in your on-premise network, as well as the public IP address of you VPN device.
Configure this network with all the subnets that you run in your on-premise network, as well as the public IP address of you VPN device.
§ Add at least one DNS server to Windows
Azure
These can be any DNS server; on-premise, in Windows Azure and public DNS. All the servers you add will be assigned with Windows Azure DHCP to your VMs.
These can be any DNS server; on-premise, in Windows Azure and public DNS. All the servers you add will be assigned with Windows Azure DHCP to your VMs.
§ Set aside one subnet within the networks you
created in Windows Azure to be the link-network
This network represents the link between you and Windows Azure. It must be within the boundary of the networks you created in Windows Azure in the previous step.
This network represents the link between you and Windows Azure. It must be within the boundary of the networks you created in Windows Azure in the previous step.
§ Enter the public IP of your VPN device
The VPN device cannot be behind a NAT, not even a 1:1 NAT with public IPs.
The VPN device cannot be behind a NAT, not even a 1:1 NAT with public IPs.
§ Start the Windows Azure Gateway
These are high-level
steps. The Windows Azure documentation goes into great detail about how to
configure your cloud networks etc. This post focuses on using Windows Server as
you local VPN device so I will not repeat the specific steps here. Instead I
refer you to the documentation:
§ Establish a Site-to-Site VPN Connection
http://msdn.microsoft.com/en-us/library/windowsazure/jj156210.aspx
http://msdn.microsoft.com/en-us/library/windowsazure/jj156210.aspx
§ Create a Virtual Network for Cross-Premises
Connectivity
http://www.windowsazure.com/en-us/manage/services/networking/cross-premises-connectivity/
http://www.windowsazure.com/en-us/manage/services/networking/cross-premises-connectivity/
After completing the
setup in Windows Azure you are ready to configure your local device.
The Windows Server
2008 R2 machine you will be using as your VPN device must have hotfix 2523881
installed. This patch enables the old Windows Server 2003 mode of NAT-Traversal
(NAT-T) which is required by Windows Azure Gateway. If you do not have this
hotfix installed, you will receive traffic into your network but return traffic
will not work. Here is the link to the hotfix:
§ You cannot establish an IPsec tunnel to a
computer that is running Windows 7 or Windows Server 2008 R2 through a NAT
device
http://support.microsoft.com/kb/2523881
http://support.microsoft.com/kb/2523881
The Local Network
This is the local
network topology in my test environment:
Our task here is to
connect our on-premise network with our Windows Azure networks and then promote
a server in Windows Azure to a domain controller for our Active Directory
domain.
Routing
Your local VPN server
does not need to be the default gateway for your local network, but if it is,
it will make your setup easier. Suffice it to say that you need to work out the
routing requirements in your environment. In this example I assume that the VPN
server is also your local default gateway. Your VPN server should not have a
default gateway IP set on the NIC connected to the local network (LAN). If you
require custom routing use RRAS, the route command or NETSH to set up your
routes.
The VPN server
Your local Windows
Server machine needs at least two NICs, one connected to your local network and
one to the public Internet. The server does not need to be joined to your
domain. I highly recomment you keep the Windows Firewall enabled on the VPN
server. Having a server directly connected to the Internet without a firewall
is not a good idea.
High level setup steps
§ Document the public IP of your VPN server and
the public IP of your Windows Azure Gateway endpoint, as well as your Windows
Azure networks and local networks. You will need these during setup.
§ Find you IPSec encryption key from the Windows
Azure portal.
§ Enable routing
§ Configue IPSec tunnel
§ Verify connectivity
§ Add VM in Windows Azure and promote to domain
controller.
To make a Microsoft Virtual Site-2-Site VPN Gateway with
Microsoft Azure follow the next step-by-step guide :
Go to the Management portal of Microsoft Azure : https://manage.windowsazure.comand login with your ID.
When you don’t have a Microsoft Azure subscription you can get a Free Trail here
When you don’t have a Microsoft Azure subscription you can get a Free Trail here
§
The name of your Virtual Network in Microsoft Azure ( We called
it YellowAzure Because we have also a Private Cloud called YellowTenant )
§
Select the region
§
And we Created a new Affinity Group Name called
YellowAffinityGroup
Here we set two items for the Site-2-Site VPN Gateway :
§
Our DNS Server on-premisses YellowDC01 with IP-address
192.168.101.4
§
And we mark checkbox Configure a Site to Site VPN
More information on Virtual Network Overview
in Microsoft Azure is here
§
The Name of the On-Premisses VPN Site, we called YellowTenant.
§
The outside IP-Address of your VPN Device, that’s our Microsoft
RAS Server. ( Remote Access Server)
§
And you add the local address Space, in our case
192.168.101.0/24
Here we select the Address Space for the
Microsoft Windows Azure VM’s with the subnets and Gateway range.
Retreive the IPSec encryption key
Log on to the Windows
Azure portal and select Networks. Click the network your are connectin your
on-site network to and select View Key (you will find this at the bottom of the
screen):
Copy the displayed
key:
Enable routing
Install the Routing
and Remote Access (RRAS) Role Service which is part of the Network
Policy Server and Access Services role. You will need to select both
Remote Access Service and Routing, one cannot be installed without the other.
You can do this either through Server Manager or PowerShell.
The PowerShell command
is:
Add-WindowsFeature NPAS-RRAS-Services
–IncludeAllSubFeature
Enable and configure
Routing and Remote Access for LAN routing only. Right click Routing and Remote
Access and select Configure and Enable Routing and Remote Access:
Select Custom
Configuration and the select LAN Routing:
What this step does is
turn Windows into an IPv4/IPv6 router. It simply tells it to start forwarding
IP datagrams. Unless you have special routing requirements in your environment
you are finished with configuring RRAS.
Configure the IPSec tunnel
In Windows Server 2008
and newer IPSec settings have been merged into the Windows Firewall.
1. Open Windows
Firewall with Advanced Security and select Connection Security
Rules:
2. Right click and
select New Rule. On the Rule Type page,
select Tunnel:
3. On the Tunnel
Type screen, leave the default Custom configuration and No for
IPSec exemptions selected and click Next:
4. On the Requirements screen
leave the default: Require authentication for inbound and outbond
connectionsselected and click Next:
5. Next, on the Tunnel
Endpoints screen, configure the tunnel endpoints and networks. (You
will have to scroll down to configure the networks for Endpoint 2):
NOTE: It is extremely important that the networks you define here match your local network configuration in Windows Azure or your traffic will not be routed.
6. On the Authentication
Methods screen, select Advanced and then press
the Customize button:
7. In the Customize
Advanced Authentication dialogue add a Preshared key authentication
for the First Authentication Methods:
8. On the Profile screen
select the Firewall Profiles for which this rule will apply. Usually it will be
all three:
9. At the Name screen,
give the rule an appropriate name and description:
10. Windows Azure
Gateway requires that you change the TCP Maximum Segment Size (MSS) to aviod
fragmentation. You do this with NETSH on your external (Internet facing)
interface. First list your interfaces:
netsh interface ipv4
show subinterfaces
In the Interface
column you should recognize your interface names. Now change the TCP MSS value:
netsh interface ipv4
set subinterface “<name of interface>” mtu=1350 store=persistent
Run the first NETSH
command again to verify the change.
11. Configure the
IPSec Quick Mode key lifetimes. Windows Azure Gateway uses a Quick Mode (Phase
2) key lifetime of 1 hour (3600 seconds) or 100 GB of traffic, whichever
happens first. The Phase 1 key lifetime is 8 hours, which is the default in
Windows Server 2008 R2 so there is no need to change that.
Right click the
Windows Firewall with Advanced Security node at the top of the Windows Firewall
console, and selectProperties. Then select the IPSec tab,
and press the Customize button:
Next select the Advanced radio
button under Data protection (Quick Mode) and press the Customize button.
UnderData integrity and encryption select the entry called
ESP/SHA1/AES-CBC 128 etc. and press the Edit button:
Under Key
lifetimes the timeout value in minutes is already set correctly to 60
minutes (3600 seconds) so we only need to configure the KB timeout.
Set it to 102 400 000 KB (100 GB).
Exit out of all the
boxes by pressing OK.
NOTE: These are global
settings which affect all connection security rules on the server. If you want
to specify these settings only on the connection security rule that pertains to
Windows Azure, use NETSH. Unfortunately you cannot configur connection security
rules specific main mode or quick mode settings in the GUI. Also you cannot use
NETSH to configure global quick mode settings, only main mode settings. The
logic behind this escapes me…. If you do decide to configure rule specific
quick mode settings with NETSH, the GUI will inform you that your rule
“…contains properties that are not supported through this interface”. That said
I would actually recommend using rule specific quick mode settings because that
way you won’t have to change the computer defaults which could potentially
cause problems for other rules. Although not needed by Windows Azure Gateway,
because the default settings match the required settings, you can also
configure specific main mode rules that match e.g. endpoints, using NETSH. More
about the diffrences between the Advanced Firewall GUI and NETSH here. Also have a look at the scripts section at the end of the
post.
12. Verify that the
IPSec tunnel has been created using the Monitoring node of the
Windows Firewall with Advanced Security console. Under Security Associations you
should have an association under both the Main Mode andQuick
Mode nodes:
If you do not see any
security associations, try to ping an address in one of your Windows Azure
networks. This should establish the tunnel.
13. Verify
connectivity in the Windows Azure portal:
Add Windows Azure Virtual Machines
Now you can add
Windows Azure VMs to your Windows Azure networks. These machines will receive
IP addresses from the Windows Azure DHCP service. The addresses will be leased
to the machine for its lifetime so it will be the same as having a static IP.
Windows Azure DHCP will also configure the servers with the DNS servers you
have defined in Windows Azure. These can be both on premise and in the cloud.
The default gateways for the machines will be set to the first address on the
subet that the machine is connected to.
Verify connectivity
After the first
Windows Azure VM is online (and its firewall opened) you should be able to send
traffic across the VPN. In my case I can now ping between my Windows Azure VM
and on-premise machines:
Now I can add the make
the Windows Azure VM a domain controller:
Scripts
Since network devices
like routers and switches are usually configured using scripts, here are the
NETSH commands to configure Windows Server as a VPN device from the CLI:
1.
Enable IPv4
routing:
You don’t really need RRAS installed to make Windows Server route IPv4 traffic. You can configure the same functionality directly with NETSH. This removes the requirement for RRAS to be installed. To configure routing you must first find either the interface names or indices of your network interfaces. In this case mine are 12 and 14. 12 is the External interface connected to the Internet and 14 is the Internal interface connected to the LAN. Routing, or IP datagram forwarding, must be configured on both. Use NETSH:
netsh interface ipv4 set interface “12” forwarding=enable netsh interface ipv4 set interface “14” forwarding=enable
You don’t really need RRAS installed to make Windows Server route IPv4 traffic. You can configure the same functionality directly with NETSH. This removes the requirement for RRAS to be installed. To configure routing you must first find either the interface names or indices of your network interfaces. In this case mine are 12 and 14. 12 is the External interface connected to the Internet and 14 is the Internal interface connected to the LAN. Routing, or IP datagram forwarding, must be configured on both. Use NETSH:
netsh interface ipv4 set interface “12” forwarding=enable netsh interface ipv4 set interface “14” forwarding=enable
2.
Create connection
security rule with rule specific quick mode settings:
netsh advfirewall consec add rule name="Windows Azure" endpoint1="192.168.0.0/16" endpoint2="10.1.0.0/16" action="requireinrequireout" description="Site-to-site VPN for Windows Azure" mode="tunnel" profile="any" type="static" localtunnelendpoint="80.212.96.194" remotetunnelendpoint="168.63.16.208" protocol="any" auth1="computerpsk" auth1psk="wL8fC…" qmsecmethods="ESP:SHA1-AES128+60min+102400000kb"
netsh advfirewall consec add rule name="Windows Azure" endpoint1="192.168.0.0/16" endpoint2="10.1.0.0/16" action="requireinrequireout" description="Site-to-site VPN for Windows Azure" mode="tunnel" profile="any" type="static" localtunnelendpoint="80.212.96.194" remotetunnelendpoint="168.63.16.208" protocol="any" auth1="computerpsk" auth1psk="wL8fC…" qmsecmethods="ESP:SHA1-AES128+60min+102400000kb"
3.
Create main mode rule
that matches traffic between the local network and Windows Azure. This rule
will then be used by the connection security rule. This is a redundant step
since the default settings of Windows Server 2008 R2 match the requirements of
Windows Azure. This is just to show how it’s done…
netsh advfirewall mainmode add rule name="Windows Azure IPSec Main Mode Settings" mmsecmethods="dhgroup2:aes128-sha1" mmkeylifetime="480min,0sess" description="Main mode settings compatible with Windows Azure Gateway" endpoint1="192.168.0.0/16" endpoint2="10.1.0.0/16"
netsh advfirewall mainmode add rule name="Windows Azure IPSec Main Mode Settings" mmsecmethods="dhgroup2:aes128-sha1" mmkeylifetime="480min,0sess" description="Main mode settings compatible with Windows Azure Gateway" endpoint1="192.168.0.0/16" endpoint2="10.1.0.0/16"
4.
Configure the TCPMSS
size:
netsh interface ipv4 set subinterface “<name of interface>” mtu=1350 store=persistent
netsh interface ipv4 set subinterface “<name of interface>” mtu=1350 store=persistent
So if you combine all
the commands in a nice cmd file you have something resembling a router
configuration script.
More info on NETSH
syntax is available here:
No comments:
Post a Comment