Configure the Site-to-Site IPsec tunnel between the Windows Azure cloud and the D-Link DFL-210

Greetings

In this article, I will describe in stages the entire process of configuring the Site-to-Site tunnel between the Windows Azure cloud and the D-Link DFL-210 firewall (relevant for the DFL line of devices: 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 we enter the name and address of the local DNS (if necessary). Otherwise, we use DNS from Windows Azure, or any public
Put the checkbox "Configure a network-to-network VPN connection "

In the next step, enter the settings of our DFL:
Name: Mydfl
The IP address of the VPN device: 78.153.146.110 is the dedicated static IPv4 address of our DFL ( This is important. If DFL is over NAT, then we will fail )
Address space: 192.168.22.0/24 - local subnet, which we will connect to Windows Azure

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

Virtual subnet is created!

Go to the " Settings " of the newly created virtual network and check that we did everything correctly


On the " Dashboard " tab we see the following picture.

Click the " Create Gateway " button at the bottom of the page and select the " Static Routing " mode. Confirm your intentions by clicking " OK "

We are waiting for 10-15 minutes until Windows Azure creates a gateway for us

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

So, the gateway is created. We look, that Windows Azure gave us:
Gateway IP Address: 23.97.132.122

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

Step 2: Configure DFL

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

Here you have to make one very important note.
In the Russian DFL firmware (installed by default), such wonderful encryption methods as AES, which Windows Azure uses (and not only) for its work, are not available. We will leave discussions on this topic outside of this article and use the following trick:
We follow the link http://tsd.dlink.com.tw/
Choose your DFL model from the list and download the latest WorldWide firmware for our device (denoted “For WW”)
Download the firmware in our DFL and wait for the completion of the operation
Firmware uploaded and we can continue

Now let's add all the IP addresses of the cloud 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 type " Pre-shared key ":
Name: Habratest_cloud_key
Passphrase: R9GrgLgZPosdZ7isMdt8MkrDQnfBwUbO

Next, go to the " Objects-> VPN Objects-> IKE Algorithms " item and create a new IKE algorithm:
Name: Habratest_cloud_stage1
We put the daws: 3DES and AES (128,128,256), as well as the SHA1 checkbox

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

Now let's proceed directly to creating a rule for an 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 point “ Pre-shared key ” and choose our “ Habratest_cloud_key >”

Tab " IKE Settings "
IKE:
Main - DH Group 2
PFS - None
Security Association: Per Net
NAT Traversal: On if supported and NATed
Dead Peer Detection: Use

Then we create two IP Rules (“ Rules-> IP Rules ”):
Rule 1 :
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 to the DFL

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

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

---

A little about possible errors in the DFL logs:
1. statusmsg = “No request" - incorrect encryption methods are selected
2. reason = “Invalid proposal” - the same as item 1
3. reason = "IKE_INVALID_COOKIE" - the tunnel was already raised, but after that changes were made to its settings. Go to the DFL "Status-> IPsec-> Habratest_cloud_IPsec-> on 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 key keys) to your

Thanks for attention!

PS I ask you to pay attention to the comment of the habrauser DikSoft , which reports that such a scenario is officially unsupported and there may be problems