[strongSwan] Microsoft Azure Virtual Network?

John Connett jrc at skylon.demon.co.uk
Fri Aug 3 11:04:11 CEST 2012

On Wed, 01 Aug 2012 17:47:23 +0100, John Connett <jrc at skylon.demon.co.uk>  
> On Mon, 30 Jul 2012 13:37:02 +0100, John Connett  
> <jrc at skylon.demon.co.uk> wrote:
>> On Thu, 26 Jul 2012 10:15:19 +0100, John Connett  
>> <jrc at skylon.demon.co.uk> wrote:
>>> I am attempting to use strongSwan 4.5.3-5.4.1 on openSUSE 12.1
>>> (x86_64) to provide an endpoint to a Microsoft Azure Virtual Network
>>> using the 90-day free trial preview (https://www.windowsazure.com).
>I have turned up logger output and the following looks suspicious:
> 10[CFG] <2> looking for pre-shared key peer configs matching  
> 10[IKE] <2> no peer config found

The two logging messages above appear to have been emitted from the
select_config function (in libcharon/sa/ikev1/phase1.c).  The file
path suggests that this is using IKEv1.  Is this an artifact of the
charon / pluto merge in strongSwan 5?  Or is "keyexchange=ikev2" not
sufficient to cause IKEv2 to be used?

These two logging messages appear during the first exchange of
IPSEC-NAT-T (UDP 4500) packets.  The first, from right to left, has a
Non-ESP Marker and an ENCRYPTED_V1 payload containing a ID_V1 payload
(0x0A040104 - and a HASH_V1 payload.  The second, from left
to right, also has a Non-ESP Marker and the significant content
appears to be:

11[ENC] <2> generating INFORMATIONAL_V1 request 1149786693 [ HASH  

I fould further information about the Azure Virtual Network on MSDN
(http://tinyurl.com/c6wkzxp).  In particular, the IPSec settings they
support are:

IKE Phase I Parameters:
     Mode: Main mode
     Encryption: AES128 or 3DES
     Integrity: SHA1
     Diffie-Hellman group: Group 2 (1024 bit)
     Authentication Method: Pre-shared key
     Security Association Lifetime: 28800 seconds

IKE Phase II Parameters:
     Mode: ESP tunnel mode
     Encryption: AES128 or 3DES
     Integrity: SHA1
     Perfect Forward Secrecy: OFF
     Diffie-Hellman group: Group 2 (1024 bit)
     Time Rekeying: ON
     Security Association Lifetime: 3600 seconds
     Security Association Lifesize: 102400000 Kbytes

I have modified my ipsec.conf to try to match these settings.
However, I couldn't see a mechanism for turning Perfect Forward
Secrecy off if a Diffie-Hellman group is specified?

They also indicate that the rightsubnet should match the whole Azure
network (TestNetwork which contains CloudSubnet
( and GatewaySubnet (

There is also the following comment:

     Does your WatchGuard router have a command to set peer-id (or
     proxy-id) for IKE Phase 1 negotiation (I will be very surprised if
     it does not have such an option, : ))? Please use that command to
     set the peer-id/proxy-id to be This address you see
     is actually the IP address of the Azure gateway (i.e. the peer of
     your WatchGuard router). 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).

In my case, the private IP address of the Azure gateway appears to be as supplied in the ID_V1 payload.  I have tried adding it to
the selectors in ipsec.secrets but with no obvious effect.  Is there
an equivalent strongSwan mechanism or setting?
John Connett

==== /usr/local/etc/ipsec.conf========================================
# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup

# VPN connections

conn Azure

==== /usr/local/etc/ipsec.secrets ==================================== : PSK "<secret>"

More information about the Users mailing list