Azure Site-to-Site VPN with a Netgear FVS318N

Azure supports two types of VPN connections.  Site-to-site bridges your internal network to an Azure VLAN effectively creating a single large routable network.  Point-to-site joins a single machine to an Azure VLAN effectively putting that machine behind the Azure firewall. You can get a high level overview of this from previous blog.  I also walked through how to create a point-to-site in a previous blog.

I wanted to join my home office network to Azure so that I had back side access to all of my IaaS machines.  These machines are all installed on a VLAN (10.0.2.x) with ACLs blocking external port access.

My home office runs with a single public IP with a Netgear FVS318N VPN capable firewall behind my cable modem. I do not have a complicated nested network.  The office is a 192.168.1.x network in a NAT configuration behind the Netgear. Some Microsoft documents recommend a Windows RRAS server with multiple LAN cards in it. One LAN card connects to the CableModem/DSL adapter and the other card connects to the internal network.  I'm personally a fan of low power/cost appliances and already have a NetGear VPN router at my front door.

Static vs Dynamic Azure Gateways

Azure now supports static and dynamic VPN gateways.  They usually recommend dynamic gateways which support both point-to-site and site-to-site gateways. You can run both VPN types with dynamic gateways but only site-to-site with static gateways.  Static gateways can use IKEv1 as a security protocol while dynamic gateways seem to require IKEv2.  I was running a dynamic gateway at the start of this test because also use point-to-site VPN connections.  I could never get my FVS318 (N) to work with IKEv2 so I tore down my gateway, gave up point-to-site and, rebuilt my Azure gateway in a static configuration. This let it use IKEv1 which is mostly compliant with the Netgear.

You can use the Azure Management Portal VPN wizard to set this up. I found that I had to go in and tweak settings because I never got right on the first try with the wizard. The following screens are a mix of Azure Management Portal wizard and regular admin screens.

We can do most of the work with Powershell.  I did all of this using the Azure Management Portal in order to get better visual feedback for the first time event.  New networks and definitions start with the "+" add button in the lower left corner of the panel. It brings up a screen similar to that on the right.

Local Network Definition

Azure needs to know the public IP address of your router on the network,.  I have a DHCP based public IP address that has not changed in the time I've had my account. It's not a static IP but it's good enough for this project. I do not have a DNS address for this IP address / device.

Click on the "plus" button in the management portal and select Network Services --> Virtual Network --> Add Local Network.  Use some unique name for the network and enter your public facing IP address of your Router.

Azure needs to know the address range of the remote network is joined to Azure by the VPN. This network address cannot overlap any of the networks / subnets in your Azure VLAN configuration. The remote network must be unique to this network. My SHO test is 192.168.1.x

Creating an Azure Virtual Network

You need to create a Virtual Network.  The first screen asks the name of this network. Note the network preview view in the lower portion of the panel.  This gets built up as you move through the process.

The next screen lets you add DNS servers and select the types of VPNs you wish to enable.  

I picked Site-to-Site only here because I needed a static gateway for my FVS318N. Selecting point-to-site requires a dyanmic gateway.

Note that we also selected the previously created Local Network as the remote network on the other side of the site-to-site VPN.

You then have to create a VLAN that includesj at least a subnet for your internal machines and a sub-net that acts as the gateway network between the internal subnet and the external (Local Machines) sub-net.  I'm pretty lazy when it comes to netmasks.  II tend to just burn extra address space to make the CIDR and net masks easy. In this case, I isolated the Virtual Machine subnet from the Gateway subnet by putting them in their own Address Space.  My address layout was

• 192.168.1.x  My internal office network
• 10.0.0.x  Reserved for my point-to-site sub-net. You don't see it here because I tore it down as part of the move to a configuration where point-to-point isn't supported.
• 10.0.1.x My Virtual machine VLAN.
• 10.0.2.x The only thing on this is a Gateway sub-net to be used by site-to-site. I've way over-allocated the size of this address space but it simplified how my sub-nets and addresses are used.

Once you are complete, you should be able to see all of your VPN, VLAN and subnetconfiguration on the network Configure screen.  You have not yet created the VPN gateway required.  Flip over to the Dashboard screen for your network. You should see a picture with a broken gateway that tells you a gateway has not yet been created.  

Select the Create Gateway icon at the bottom of the Azure Management page for that network. A small popup list should offer Static and Dynamic options. Select Static for the FVS318. It will take a long time for Azure to create the gateway.

Eventually Azure will complete creating the gateway. The Network diagram on the Dashboard should look something like what is on the right.

Note that these three pictures show a point-to-site connection that you will not see since you are only creating a site-to-site VPN 

Provisioning a Couple Virtual Machines on the VLAN

I created a couple virtual machines at this point so that I had something to test with. You should create them on the VLAN subnet mentioned above.  This Dashboard screen shows my VLAN configuration including my gateway and two virtual machines. Note the Static Routing gateway type in the lower right corner.

Retrieving the VPN Shared key and Other Configuration

You need to get Azure VPN shared key to enter into the FVS318 VPN configuration screens.  you can either get it by clicking on the Manage Key button at the bottom of the Dashboard screen or by downloading it as pat of a VPN configuration script.  You will visually scan the script for needed information. The Netgear cannot read the configurations script directly.

Configuring the NetGear FVS318N

Run the FVS318G VPN wizard. It will create linked IKE and VPN policies that define your VPN link.  Fill in the values per your configuration.  You will  need your Azure pre-shared key, the Azure gateway address, the public IP of your router and the address and netmask of the VLAN subnet you defined in Azure.

You will end up with a VPN Policy and an IKE policy.  The VPN Policy configuration refers to the IKE policy, using it as its identity profile.

VPN Profile

The VPN policy defines the the network topology using the local network subnet and the remote network. The VPN router will create routes for these two networks once the connection is made.

Look at the VPN policy and verify the settings including the Remote Endpoint, Local network, the Remote (Azure) network, the timeout in either kbytes or seconds, the Authorization Algorithm and the Encryption algorithm. Netgear picked the wrong default Encryption Algorithm.

IKE Profile

The VPN policy defines the connection setup and authentication policies. It is referred to by the VPN Policy which must be disabled if you choose to change any of the IKE parameters.  There is no obvious way to specify IKEv1 vs IKEv2. I was never able to create a VPN tunnel when Azure required IKEv2 so I picked a static Azure gateway which works with IKEv1.

Look at the IKE policy and verify the local and remote IP addresses. These are the public endpoints of the VPN tunnel. Verify the shared key and set the encryption algorithms.  NetGear picked the wrong Encryption Algorithm on my FVS318G.

Remember to re-enable the VPN profile after editing the IKE profile.

Logs

You should see something in the Netgear VPN Logs that looks like the following. I did not have to manually start my connection.

... [FVS318N] [IKE] INFO:  [IPSEC_VPN] IPsec-SA established: ESP/Tunnel <public ip>-><azure ip> with spi=3040560578(0xb53b45c2)

... [FVS318N] [IKE] INFO:  [IPSEC_VPN] IPsec-SA established: ESP/Tunnel <azure ip>-><public ip> with spi=188096152(0xb361e98)

... [FVS318N] [IKE] WARNING:  Ignore CONNECTED notification from <azure ip>[500].

... [FVS318N] [IKE] WARNING:  attribute has been modified.

... [FVS318N] [IKE] WARNING:  Ignore RESPONDER-LIFETIME notification from <azure ip>[500].

... [FVS318N] [IKE] INFO:  Initiating new phase 2 negotiation: <router ip>[500]<=><public ip>[0]

... [FVS318N] [IKE] INFO:  Sending Informational Exchange: notify payload[608]

... [FVS318N] [IKE] INFO:  ISAKMP-SA established for <public ip>[500]-1<azure ip>[500] with spi:<some big string deleted>

... [FVS318N] [IKE] INFO:  NAT not detected 

... [FVS318N] [IKE] INFO:  NAT-D payload matches for <azure IP >[500]

... [FVS318N] [IKE] INFO:  NAT-D payload matches for <router ip >[500]

... [FVS318N] [IKE] INFO:  For <azure ip >[500], Selected NAT-T version: RFC 3947

... [FVS318N] [IKE] INFO:  Received unknown Vendor ID

... [FVS318N] [IKE] INFO:  Received unknown Vendor ID

... [FVS318N] [IKE] INFO:  Received unknown Vendor ID

... [FVS318N] [IKE] INFO:  Received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

... [FVS318N] [IKE] INFO:  Received Vendor ID: RFC 3947

... [FVS318N] [IKE] INFO:  Received Vendor ID: MS NT5 ISAKMPOAKLEY

... [FVS318N] [IKE] INFO:   [isakmp_ident.c:190]: XXX: setting vendorid: 9

... [FVS318N] [IKE] INFO:   [isakmp_ident.c:190]: XXX: setting vendorid: 8

... [FVS318N] [IKE] INFO:   [isakmp_ident.c:190]: XXX: setting vendorid: 4

... [FVS318N] [IKE] INFO:   [isakmp_ident.c:186]: XXX: NUMNATTVENDORIDS: 3

... [FVS318N] [IKE] INFO:  Beginning Identity Protection mode.

... [FVS318N] [IKE] INFO:  Initiating new phase 1 negotiation: 98.231.146.71[500]<=>137.135.98.3[500]

... [FVS318N] [IKE] INFO:  Configuration found for <azure IP >.

... [FVS318N] [IKE] INFO:  Configuration found for <azure IP >.

... [FVS318N] [IKE] INFO:  accept a request to establish IKE-SA: 137.135.98.3

Issues

The connection appears to continually restart. I didn't notice any issues while using the VPN but it looks like there are still some configuration issues.

This configuration works and provides all expected access. I verified this with ACLs that blocked all external access.  There is still some problem that appears in the logs where the VPN tunnel continually disconnects and reconnects.  The rudimentary logs show that the connection continually restarts. I don't know enough about VPN plumbing to understand what is going on. Azure itself provides no log output that I can find.

The VPN stays up all the time once you've configured it. You can only bring down the VPN link by disabling the connection in the Netgear FVS318 VPN administration screen.

Other Useful Articles

• IKE1 , IKEV2 in the Azure environment with Static and Dynamic Azure gateways: http://blogostuffivelearnt.blogspot.com/2013/10/ipsec-vpns-and-ike.html
• An example using a router where someone had a dedicated VPN IP address http://www.bhargavs.com/index.php/2013/05/16/azure-vpn-behind-nat-on-the-cheap/
• An gateway overview discussing how static and dynamic gateways differe in Azure: http://msdn.microsoft.com/en-us/library/windowsazure/jj156075.aspx

Azure acess models

Azure is primarily aimed at public facing services and web sites. You can see this in the way some Cloud Service features are only available at Azure's public edge.  Azure provides the ability to interact  machines remotely through the public ports and services. Sometimes you don't want everything exposed to the internet so you can get access to it. A VPN can be used in those cases provide secure no public machine-to-network or network-to-network connectivity

Standard Access

Applications and services are deployed in the Azure environment as a kind of virtual data center.  Individual machines and programs communicate with each other using the internal Azure network.  Azure virtual machines can also communicate from Azure to other sites on the internet. Machines external to Azure normally communicate with Azure machines through their publicly defined service interface points.

Most services run on standard ports for Azure-to-Azure  communications. They can be made public through the endpoint configuration screen. Notice that there is a public port accessible via the cloudapp.net address and a private port accessible internally to Azure via internal DNS or via direct IP access. I was unable to find a way of turning on private only endpoints through the Azure administrative portal.

Access Control and Security

Public ports, services and applications are reachable from anywhere on the internet.  This can be a major security issue since Azure machines are probed almost as soon as they are created. 

Azure supports Access control lists on a per endpoint basis.  Each endpoint on a server can have its on ACLs. This example shows an endpoint that is visible from a specific external network, from two Azure VLANs internal to this Azure subscription. All other systems are blocked.  The most restrictive policy should come last.  

Point to Site VPN 

A point to site VPN tunnel puts a non-Azure machine on a private network that is essentially inside Azure. You can think of it a as a virtual LAN card in the remote device that is connected to the Azure network. Machines connected via point to site have access to the back site (private) ports. Almost all MS Windows machines come with software to support this type of connectivity. Point to Site VPN connections happen through an Azure  Gateway that is created as part of a VLAN.  This is done via Powershell or via the Azure Management Portal.  

See this posting azure-point-to-site-vpn-private-access about how to set up Azure point-to-site connections.

Site to Site VPN

Office to Data Center and Data Center to Data Center connections are made through site to site connections.  This joins the two networks together and set up routes that give back side access to any Azure machine from any machine the remote site.  This also removes the need for individual machine VPN configuration. Site to Site connections happen through an Azure side  Gateway that is created as part of a VLAN.  THis is done via Powershell or via the Azure Management Portal.

See this posting azure-site-to-site-vpn-with-netgear about how to set up an Azure site-to-site connection using a NetGear VPN capable router.

Site to Site Security Implications

The Azure site-to-site bridge adds a second public facing network to your network with a it's set of public ports and services.  A corporation's internal network is only as secure as the least secure Azure machines.  

The diagram at left shows a potential attack path from the internet through an Azure machine, over the site-to-site tunnel and into the office LAN.

All administrative ports and non-public services must be protected through Azure ACLs

Wrap Up

This discussion applies to both IaaS virtual machines and PaaS services.