[strongSwan] Microsoft Azure Virtual Network?
jrc at skylon.demon.co.uk
Mon Aug 6 12:55:02 CEST 2012
On Fri, 03 Aug 2012 10:14:01 +0100, Martin Willi <martin at strongswan.org>
>> > 10[CFG] <2> looking for pre-shared key peer configs matching
>> > 192.168.199.10...126.96.36.199[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:
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 - 188.8.131.52)
10.4.1.5:500 private IP (in GatewaySubnet 10.4.1.0/24)
184.108.40.206:1032 public IP (Azure Gateway)
220.127.116.11: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.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:
Chose the strongSwan host as this IP address will find that the
interface is local (eth0).
The HomeSubnet of the clients.
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?
The public IP address of the Azure Gateway.
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).
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 18.104.22.168 22.214.171.124 %any : PSK "<secret>"
However, even with %any specified there was "no peer config found".
Will continue to investigate ...
More information about the Users