[strongSwan] Microsoft Azure Virtual Network?

[John Connett]

On Fri, 03 Aug 2012 10:14:01 +0100, Martin Willi <martin at strongswan.org>  
wrote:
>> > 10[CFG] <2> looking for pre-shared key peer configs matching
>> > 192.168.199.10...168.63.60.212[10.4.1.4]
>> > 10[IKE] <2> no peer config found
>>
>> Is this an artifact of the charon / pluto merge in strongSwan 5?  Or is
>> "keyexchange=ikev2" not sufficient to cause IKEv2 to be used?
>
> The keyexchange parameter is connection specific, so your connection
> will use IKEv2.
>
> Your peer, however, seems to initiate with IKEv1. You don't have a
> matching connection for IKEv1, hence the negotiation fails with "no peer
> config found".

I have added:

     keyexchange=ikev1

so both initiator and responder should now be using IKEv1.

I have tried a number of changes to ipsec.conf and the selectors in
ipsec.secrets but all of them fail with "no peer config found".  My
guess is that the problem is with the left and right options for IP
addresses and selectors.

My objective is for clients in HomeSubnet to use a server in
CloudSubnet.  The path from right to left is:

        10.4.2.4         server (hotol.cloudapp.net - 168.63.40.163)
        10.4.2.0/24      CloudSubnet
        10.4.0.0/16      TestNetwork
        10.4.1.5:500     private IP (in GatewaySubnet 10.4.1.0/24)
   168.63.60.212:1032    public IP (Azure Gateway)
        Internet
    86.30.202.35:500     public IP (VPN Gateway - skylon.dyndns.org)
   192.168.199.1:500     openWrt router
  192.168.199.10:500     strongSwan host
   192.168.199.0/24      HomeSubnet
   192.168.199.6         example client

Note that 10.4.1.5:500 was obtained by brute force from a right to
left NAT-D hash of address and port.  10.4.1.5 also appears in the
ID_V1 payload of the first right to left encrypted message to port
4500.  The right side always appears to become the initiator.

Here are my thoughts on the ipsec.conf settings:

     left=192.168.199.10

Chose the strongSwan host as this IP address will find that the
interface is local (eth0).

     leftsubnet=192.168.199.0/24

The HomeSubnet of the clients.

     leftsourceip=%config

Less sure about this.  Assume that this internal source IP for the
tunnel is in GatwaySubnet (10.4.1.0/24) and requested from the peer?

     right=168.63.60.212

The public IP address of the Azure Gateway.

     rightsubnet:10.4.0.0/16

TestNetwork which includes both the GatewayNetwork (10.4.1.0/24) and
the CloudSubnet (10.4.2.0/24) of the server (10.4.2.4).

     rightsourceip=%config
or
     rightsourceip=10.4.1.0/24

I think this should resolve to 10.4.1.5, the private IP address
deduced from the address and port hash and provided in the encrypted
ID_V1 payload.  Maybe the Cisco/Juniper routers that are officially
supported use this ID_V1 payload to obtain their peer id?

There is only a single PSK entry in ipsec.secrets.  Not sure which IP
addresses should be included as selectors.  I tried:

     192.168.199.10 86.30.202.35 168.63.60.212 %any : PSK "<secret>"

However, even with %any specified there was "no peer config found".

Will continue to investigate ...
--
John Connett