Configure Site-to-Site IPsec Tunnel between Windows Azure Cloud and D-Link DFL-210

Greetings!

In this article, I will describe in stages the entire process of setting up a Site-to-Site tunnel between the Windows Azure cloud and the D-Link DFL-210 firewall (relevant for the DFL device line: 210 \ 260E \ 800 \ 860E)

Attention! All configuration steps are accompanied by a large number of pictures!

Step 1: Configure Windows Azure

First, create a new Windows Azure virtual network using the wizard.

Name: Habratest
New Territorial Group: Habragroup
Region: Western Europe

Then enter the name and address of the local DNS (if necessary). Otherwise, we use DNS from Windows Azure, or any public one.
We put a daw “Configure VPN connection of the“ network-to-network ” type”

In the next step, enter the settings of our DFL:
Name: Mydfl
IP-address of the VPN device: 78.153.146.110 - this is the allocated static IPv4 address of our DFL ( This is important. If the DFL is behind NAT, then we won’t succeed )
Address space: 192.168 .22.0 / 24 - the local subnet that we will connect to Windows Azure

In the last step, we enter the settings of the subnet to which we will connect (it will be used for services created in Windows Azure)
In our case, the settings will be as follows:
Total virtual network address space: 172.16.80.0/24
Subnet:
AzureSubnet 172.16.80.0/27
Gateway 172.16.80.32/29

Virtual subnet created!

Go to the " Settings " of the newly created virtual network and verify that we did everything right


On the tab " Dashboard " we see the following picture

Click the " Create a gateway " button at the bottom of the page and select the " Static Routing " mode . Confirm your intentions with the OK button .

We wait 10-15 minutes for Windows Azure to create a gateway for us

... It took 10 to 15 minutes ...

So, the gateway is created. We look what Windows Azure provided to us: the
IP address of the gateway: 23.97.132.122

Next, click the " Key Management " button at the bottom of the page and get our personal pre-shared key:
R9GrgLgZPosdZ7isMdt8MkrDQnfBwUbO

Stage 2. Configuring DFL

General requirements for the gateway can be found here:
http://msdn.microsoft.com/en-us/library/windowsazure/jj156075.aspx#BKMK_VPNGateway

One very important point to make here.
In the Russian DFL firmware (installed by default), such wonderful encryption methods as AES, which Windows Azure uses (and not only), are not available. We will leave discussions on this topic outside the scope of this article and use the following trick:
Follow the link http://tsd.dlink.com.tw/
Select your DFL model from the list and download the latest WorldWide firmware for our device (indicated as “For WW” )
Download the firmware to our DFL and wait for the operation to complete. The
firmware is loaded and we can continue

Now let's add all the cloud's IP addresses to the directory (" Objects-> Address book-> InterfaceAddresses ):
Name: Habratest_cloud_gateway
Value: 23.97.132.122
Name: Habratest_cloud_subnet
Value: 172.16.80.0/24

Then go to " Objects-> Authentication Objects " and add a new object of the " Pre-shared key " type:
Name: Habratest_cloud_key
Passphrase: R9GrgLgZPosdZ7isMdt8MkrDQnfBwUbO

Next, go to the item “ Objects-> VPN Objects-> IKE Algorithms ” and create a new IKE algorithm:
Name: Habratest_cloud_stage1
Put the daws: 3DES and AES (128 128 256), as well as the daw SHA1

After creating the IKE algorithm, we proceed to creating the IPsec algorithm ( "Objects-> VPN Objects-> IPsec Algorithms" ):
Name: Habratest_cloud_stage2 Jackdaws
: the same as IKE

Now we proceed directly to creating the rule for the IPsec tunnel ( “Interfaces-> IPsec” ): General
tab Name: Habratest_cloud_IPsec Local Network: lannet Remote Network: Habratest_cloud_subnet Remote Endpoint: Habratest_cloud_gateway Encapsulation mode: Tunnel ( important setting! ) IKE Config Mode Pool: None IKE Algorithms: Habratest_cloud_stage1 IKE Lifetime: 28800 IPsec Algorithms: Habratest_cloud_stage2 IPsec Lifetime: 3600 sec IPsec Lifetime: 102400000 Kb














“Authentication” tab
Put the “ Pre-shared key ” point and select our “ Habratest_cloud_key >”

Tab « the IKE the Settings »
the IKE:
the Main - the DH Group is 2
the PFS - to None
Security Association: Net Per
the NAT Traversal of: the On the if supported NATed and
Dead Peer Detection's: the Use

Then we create two IP Rules (“ Rules-> IP Rules ”):
Rule1 :
Name: lan_to_cloud
Action: Allow
Service: All_service
Schedule: None
Source interface: lan
Source Network: lannet
Destination Interface: Habratest_cloud_IPsec
Destination Network: Habratest_cloud_subnet

Rule 2 :
Name: cloud_to_lan
Action: Allow
Service: All_service
Schedule: None
Source interface: Habratest_cloud_IPsec
Source Network: Habratest_cloud_subnet
Destination Interface: lan
Destination Network: lannet


So we created the basic settings for the tunnel. Now save and apply the changes made to the DFL.

That's all! We observe beautiful pictures of the raised tunnel

Next, you can create the necessary services in Windows Azure (virtual machines, databases, etc)

---

A little bit about possible errors in the DFL logs:
1. statusmsg = “No proposal chosen” - the encryption methods are not correctly selected
2. reason = “Invalid proposal” is the same as item 1
3. reason = “IKE_INVALID_COOKIE” - the tunnel is already was raised, but after that changes were made to its settings. We go to the DFL "Status-> IPsec-> Habratest_cloud_IPsec-> at the top right of the List all active IKE SAs" page and delete the outdated IKE SA. Reboot DFL

---

That's all. Do not forget to change the test data from the article (IP addresses, subnets, regions, pre-shared keys) to your own

Thank you for your attention!

PS Please pay attention to the comment of the Habrauser DikSoft , which reports that such a scenario is officially unsupported and there may be problems