Jesper M. Christensen

SharePoint and Security

Creating a Windows Azure virtual network with site-to-site VPN to SonicWALL

One of the great new features of Windows Azure is the ability to create a site-to-site VPN connection to your local network.

Microsoft delivers configuration instructions for Cisco and Juniper and currently only deliver information and step-by-step configuration details for these devices.

In this blogpost I will guide you through configuring a new virtual network to a SonicWALL device through the Windows Azure web portal.

Creating a Local Network

For establishing the connection to a local network you can define your local network before actual creating a new Virtual Network in Windows Azure. This will give you the possibility to create a site-to-site connection in the “New Virtual Network” configuration wizard.

Access the network configuration section in the Windows Azure web portal.

Click the tab called “Local Networks”

Here you click “+ Create” button on the bottom of the page.

Fill out the Name and the public IP address of the VPN gateway.

Then click the next-arrow to proceed to step 2.

You will fill out the subnet(s) and click the checkmark button to create this entry.

Creating a new Virtual Network and the gateway connection in Windows Azure

It is vital that you create the virtual network before you create the virtual machines in Windows Azure as it is not easy to change to another network for the machines (at the moment).

You will access your portal and click the “+ NEW” button and select “Network” and “Custom Create”

Here you will fill in details regarding the network such as Name, Region to be used and select or create an affinity group.

Then click the next-arrow to proceed to step 2.

Here you will create your address space and subnets. It is important that you know a bit about subnetting as the address space must include all the subnets you create. The address space is used for “grouping” the addresses and will be used for routing and the VPN tunnel. The network is virtualized and do not conflict with any other networks in Windows Azure.

I create two subnets as the screenshot shows.

Then click the next-arrow to proceed to step 3.

On this configuration screen you will choose a DNS (if any, the default is a Windows Azure default). If you need to create additional domain controllers for an existing domain from your local network it could be a good idea to fill this out.

This is also the page where you configure the actual connection to the local network. You will type in the subnet of the Windows Azure network that is available for the local network. In this example I will provide access to all my Windows Azure subnets.

Click the checkmark button to create the new Virtual Network and configure the Windows Azure VPN connection.

Note: You cannot change the VPN connection details without deleting the gateway. This takes a while and will delete the Windows Azure VPN entry. Afterwards you can create a new gateway and VPN connection again for this Virtual Network.

Configuring the SonicWALL for the VPN connection to the Windows Azure gateway

This example is made from a SonicWALL with an enhanced firmware installed. The enhanced firmware is not required for this to work and just use the same configuration details for a standard firmware.

Log on to your SonicWALL as an admin and go to the “Network” and “Address Objects” menu.

Create a new Address Object (and possibly an Address Group also for future reconfigurations) that defines the Windows Azure network used in the VPN tunnel.

Now you will start the VPN configuration wizard from the button in the upper right corner of the SonicWALL – click Wizards and choose “VPN Wizard”

Choose Site-to-Site

Fill in a name, the preshared key and the Remote Peer IP Address. You can find this by accessing the Windows Azure web portal, go to the “Networks” area and clicking your Virtual Network. On this dashboard you can see the “Gateway IP address” which you will use. The preshared key can be found by clicking the “View Key” on the same page.


Select which subnets you want the Windows Azure networks to access internally and the Windows Azure networks created before

Now select the security settings for this tunnel. This can be different in your configuration or future Windows Azure standards and can be found in the configuration script generated by the Windows Azure Virtual Network Download-wizard. Download the file and check the content.

Now you can complete your wizard and both NAT entries and the VPN tunnel will be created.

Edit the VPN tunnel and configure the ID’s for this tunnel to match the public IP of the SonicWALL and the internal Windows Azure gateway IP (you can see this in the SonicWALL log in an error message. Microsoft could change the settings to support other VPN vendors that do not support their auto-IP-ID configuration):

Also check the proposals section for this – The exchange method must be set to “Main mode”

To active this you can try pinging an address on the remote subnet and you should be able to reach this after the VPN tunnel has initialized. Alternatively you can enable the “Keep alive” on the “Advanced” tab of the VPN tunnel configuration on the SonicWALL.

Note: All Windows Azure Windows Servers has activated the Windows Firewall and you need to either disable the firewall (not recommended!) or add an allow-entry for ICMPv4 traffic in this.

You can check the status of the site-to-site connection on the Windows Azure web portal “Networks” area and clicking your Virtual Network.

I hope this guide helps you configuring a site-to-site tunnel between the networks.


23 responses to “Creating a Windows Azure virtual network with site-to-site VPN to SonicWALL

  1. Pingback: Windows Azure – Can we use it for SharePoint now? « Jesper M. Christensen

  2. Bruce McMillan August 3, 2012 at 15:55


    Just a follow up. I got this working but one point that you might already have in your system that is not on the blog entry is that under

    VPN –> Advanced Settings. The enabel NAT Traversal needs to be ticked or you connect but get no routing between sites.

    Thanks very much for your tutorial though !


  3. Tim September 17, 2012 at 17:25

    Thank you for posting this, it helped greatly. The trick about finding the Azure Gateway IP address in the log was especially helpful.

  4. Tim Robinson September 20, 2012 at 15:18

    I got this working thanks to your article but I’ve noticed that the Peer IKE ID sometimes gets changed on the Azure side causing me to have to go in and set it to get the tunnel back up. Is there any work around for this?

  5. Justin January 29, 2013 at 21:05

    I have Nat Traversal on but i cannot ping. Also I cannot find this internal gateway IP you mention. I do not see anything in the logs

  6. February 10, 2013 at 23:36

    “Creating a Windows Azure virtual network with site-to-site
    VPN to SonicWALL Jesper M. Christensen” was a very good read and thus I really
    was pretty satisfied to come across the blog. Thanks a lot,Marilou

  7. Leonard March 2, 2013 at 15:10

    What exactly seriously encouraged you to write “Creating a Windows Azure virtual network with
    site-to-site VPN to SonicWALL | Jesper M. Christensen” melianband ?
    Igenuinely loved the blog post! Regards -Esperanza

  8. Ronald March 11, 2013 at 06:29

    Hi Jesper,

    I search all over and couldn’t find a reference how to use Sonicwall VPN with Azure and then I found this wonderful article! I have a question, in the “Add Local Network” , you didn’t mentioned what value to put in the next step in the “Address Space”, is this the address space that was configured for the Sonicwall or is this the address space that was configured for Azure like the one you setup for the “Virtual Network” > “Address Space and Subnets” which is ? Another question, where can I find the “Peer IKE ID” ? I tried looking in the Logs > View , I couldn’t find any error message, just some warnings and info like this > Warning VPN IKE IKE Initiator: Proposed IKE ID mismatch.
    Can you give me the example of the log so I know what I should be looking for? Appreciate your help on this!


    • jespermchristensen March 12, 2013 at 08:52

      Hello Ronald,

      The subnet(s) are the IP subnet(s) on your local LAN (e.g.

      I do not have a log where I am now, but I will try finding this for you and post it here.


    • Steve March 21, 2013 at 17:29

      Any joy on the, I am getting this same error? I am on a TZ215

      VPN IKE IKE Initiator: Proposed IKE ID mismatch.



      • cdmeredith July 10, 2013 at 17:11

        On the peer IKE ID I used the gateway IP address that Azure gave me, or the same as the IPsec primary gateway, connected right away after i changed to that.

  9. Jose March 16, 2013 at 18:18

    Hi Jesperm,
    I’m trying to do the same process you relate with a TZ210, but always receive an “Received IPSec SA delete request”, the tunnel seems to be ok, always green, always connected in azure, but always making reconnections, and no communications at all…any clues?



    • jespermchristensen March 21, 2013 at 06:22

      You should be able to ping. I assume you have checked that the local Windows firewall allows you traffic in/out.

      On the Sonicwall you have some firewall and NAT rules also that could cause this. You should be able to see the statistics of the VPN tunnel – do the packets go/come from the azure Network?

      • Jose March 22, 2013 at 12:54

        I’m not able to ping. Yes local windows firewall deactivated.
        SonicWall by default create the mandatory rules in firewall to be able to access the VPN. I’ve checked and is correct.

        At windows azure, gateway connected, 67.72KB input, 0B output.
        At sonicwall, vpn tunnel statistics, everything is 0.

        Associated to the “Received IPSec SA delete request”, there are this note: “VPN Policy: VPN Azure, SPI:0xe0b7d979”, where “VPN Azure” is the name I set to the VPN Policy.


      • jespermchristensen March 25, 2013 at 14:09

        Did you use DHCP on the servers in Azure? I believe this is necessary to get through the Azure VPN and firewall rules.

      • Jose March 28, 2013 at 18:37

        I don’t understand the relation between the VPN tunnel reconnecting every few seconds, and the DHCP on the Azure server.
        The problem aren’t that we’ve a stable tunnel and I can’t ping the other side, the problem is we’ve a tunnel reconnecting every few seconds.
        I can send you the screenshots do you think are necessary to understand the real problem.

        Many thanks!!

  10. Tim April 18, 2013 at 21:18

    Thanks for this great article but it appears Microsoft has changed a few things making any new Azure Network hopelessly incompatible with the Sonicwall routers. If I look at a downloaded Juniper configuration they are now using AES256. Even if I change that setting I can’t get a connection. If anyone does have an up to date solution please post it.

  11. Justin June 26, 2013 at 02:04

    Anyone able to get this working with a dynamic gateway in azure? Azure is getting rid of Azure Connect so I must use the point to site connections and it appears that Azure only allows dynamic gateways with this setup.

  12. scott July 10, 2013 at 14:08

    Great article, thanks for posting.

    Initially worked well for me leaving the LOCAL IKE & PEER IKE blank. I could ping my VM nodes from my LOCAL network. However today I can no longer PING so I am working over this article again. Same issue as some of the responders above , not sure what to add into PEER IKE.

    Local Network (SonicWall) –
    Azure Address Space –
    Azure Subnet – (contains all VMs)
    Azure Gateway –

    I have tried entering into PEER IKE:
    But received IKE Responder: Proposed IKE ID mismatch.

    SonicWall logs show ICMP packets allowed / routing out correctly.
    Azure shows VPN connected.
    In Azure I can ping VM from VM
    Packet appears to get lost at Azure Gateway when ping from local network.

    Any ideas please ?

    Thanks for any help

    • scott July 10, 2013 at 14:33

      TELNET 3389
      TCP handshake violation detected; TCP connection dropped

      Reading up on this message:

      “In TCP, there is what is called the three-way handshake. The client sends a SYN, the server sends an ACK, the client will send a SYN-ACK, and the server will send an ACK. Each transaction will have a sequence number (SYN seq number 1, ACK seq 2, seq 1 etc..) After this point, the connection will be established. The firewall will keep track of the state of all TCP connections. Firewalls will drop connections that they see questionable TCP states. If the firewall sees an ACK with an incremented sequence number, but did not see the initial SYN with the previous sequence number, it will drop the packets related to that TCP connection. Asymmetric routing can cause problems like this. Or some firewall anti-spoofing countermeasures will drop TCP connections in which it does not see previous state entries.”

      I am currently running
      PING -n 1000
      The first PING got a response, subsequent PING (all 999 of them) did not.

      Starting to thing my gateway SUBNET is incorrect somehow.


  13. scott July 10, 2013 at 16:41

    Posted back in June 2012:

    “Unfortunately, this is currently by design (i.e. the peer IKE ID of the Azure gateway is dynamic). I cannot get into too much implementation details of this problem in the public forum (hope you can understand), but we are aware of this problem, and it is actually one of the main reasons why we do not officially support some of the VPN router products out there (e.g. WatchGuard, SonicWall, etc). As I have pointed out in the other thread with EDRandD (the WatchGuard thread), you are stepping into the unsupported territory here:

    For the Cisco/Juniper devices we officially support, none of them require such a setting to be explicitly declared, but we are also aware that some device may have such a requirement (and that’s also the reason why we do not support these devices officially at this point).

    That said, we are currently working on addressing this issue in the next release (i.e. making the peer IKE ID static). In the meantime, unfortunately, it seems your best choice is to either go with a support hardware device or keep up with this changing peer ID property (I know that’s not pleasant, I am sorry about that…).”


  14. Gold Price Live October 22, 2013 at 06:10

    I am actually happy to read this blog posts which includes tons
    of helpful information, thanks for providing such statistics.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: