Azure Site-to-Site VPN with a Netgear FVS318N

February 21, 2014

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 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: 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.

Blog de Joe Freeman