[strongSwan] Azure dynamic routing VPN and Strongswan

Kimmo K koippa at gmail.com
Thu Sep 26 20:01:25 CEST 2013


2013/9/26 Noel Kuntze <noel at familie-kuntze.de>:
> Then it maybe has a problem with the leftid you're using. Maybe it wants the leftid to be some special value instead of the IP.


Must be something like that. These are the IKE SA and IPSec SA details
from working connection using Juniper:

 IKE SA:
> show security ike security-associations detail
IKE peer azure-public-ip, Index 6253471, Gateway Name: ikegateway-azure
  Role: Responder, State: UP
  Initiator cookie: 299bcf924987e1f1, Responder cookie: 6e6feb0c30db9024
  Exchange type: IKEv2, Authentication method: Pre-shared-keys
  Local: juniper-public-ip:500, Remote: azure-public-ip:500
  Lifetime: Expires in 19739 seconds
  Peer ike-id: azure-public-ip
  Xauth assigned IP: 0.0.0.0
  Algorithms:
   Authentication        : hmac-sha1-96
   Encryption            : aes256-cbc
   Pseudo random function: hmac-sha1
   Diffie-Hellman group  : DH-group-2
  Traffic statistics:
   Input  bytes  :                84260
   Output bytes  :                76992
   Input  packets:                 1103
   Output packets:                 1008
  Flags: IKE SA is createdWaiting for remove
  IPSec security associations: 6 created, 3 deleted
  Phase 2 negotiations in progress: 0
    Negotiation type: Quick mode, Role: Responder, Message ID: 0
    Local: juniper-public-ip:500, Remote: azure-public-ip:500
    Local identity: juniper-public-ip
    Remote identity: azure-public-ip
    Flags: IKE SA is createdWaiting for remove


and IPsec SA:

> show security ipsec security-associations detail
  ID: 131073 Virtual-system: root, VPN Name: ipsecvpn-azure
  Local Gateway: juniper-public-ip, Remote Gateway: azure-public-ip
  Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Version: IKEv2
    DF-bit: clear
    Bind-interface: st0.0
    Direction: inbound, SPI: 735559cc, AUX-SPI: 0
                              , VPN Monitoring: UP
    Hard lifetime: Expires in 2337 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 1732 seconds
    Mode: Tunnel(2 10), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64
    Direction: outbound, SPI: 86a55dc8, AUX-SPI: 0
                              , VPN Monitoring: UP
    Hard lifetime: Expires in 2337 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 1732 seconds
    Mode: Tunnel(2 10), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64


For the IPsec SA, Traffic selector is 0.0.0.0/0 for local and remote.
IPsec SA is bind to interface st0.0 and traffic is route to the
interface in order to get it in to tunnel.
I don't wan't to use 0.0.0.0/0 traffic selectors, maybe I can use
libipsec and routes but that is another issue.


But I'll keep trying, I appreciate any ideas how to get this working.


Regards,
Kimmo











> Regards
> Noel Kuntze
>
> On 26.09.2013 19:28, Kimmo K wrote:
>> Hello Noel
>>
>> I think it just sends cert request but still wants to do PSK. There is
>> no option to use certificates, as fas as I have understood the azure
>> admin portal. I can only set and reset PSK.
>>
>> I can also download configuration script for different VPN servers,
>> such as MS RRAS (Windows Server 2008 and 2012), which has line:
>>
>> #Add-VpnS2SInterface -Protocol IKEv2 -AuthenticationMethod PSKOnly
>> -NumberOfTries 3 -ResponderAuthenticationMethod PSKOnly -Name
>> azure-public-ip-Destination azure-public-ip -IPv4Subnet
>> @("10.96.97.0/24:100") -SharedSecret azure-psk
>>
>> and if I download configuration script for Juniper, it has:
>>
>> #set security ike proposal azure-proposal authentication-method pre-shared-keys
>> #set security ike policy azure-policy pre-shared-key ascii-text azure-psk
>>
>> Maybe the problem is in IDr payloads, because PSK seems to be correct.
>> I was expecting problems in traffic selectors, but I guess that would
>> cause "No proposal chosen" or something similar.
>>
>> Regards,
>> Kimmo
>>
>>
>>
>> 2013/9/26 Noel Kuntze <noel at familie-kuntze.de>:
>>>
>> Hello Kimmo,
>>
>> The responder wants to get a certificate. It therefore sends you 24 certificate requests.
>> I think, that Azure wants you to authenticate using a signed certificate.
>> Look for that line:
>> >>> Sep 26 15:04:21 11[IKE] received 24 cert requests for an unknown ca
>>
>> Regards
>> Noel Kuntze
>>
>> On 26.09.2013 18:37, Kimmo K wrote:
>> >>>  Hello
>> >>>
>> >>> I have tried to get this up and running with 5.1.0, having some problems:
>> >>>
>> >>> # strongswan up to-azure
>> >>> initiating IKE_SA to-azure[1] to azure-public-ip
>> >>> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
>> >>> sending packet: from ss-public-ip[500] to azure-public-ip[500] (648 bytes)
>> >>> received packet: from azure-public-ip[500] to ss-public-ip[500] (845 bytes)
>> >>> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V CERTREQ ]
>> >>> received unknown vendor ID:
>> >>> 1e:2b:51:69:05:99:1c:7d:7c:96:fc:bf:b5:87:e4:61:00:00:00:09
>> >>> received unknown vendor ID: fb:1d:e3:cd:f3:41:b7:ea:16:b7:e5:be:08:55:f1:20
>> >>> received 24 cert requests for an unknown ca
>> >>> authentication of 'ss-public-ip' (myself) with pre-shared key
>> >>> establishing CHILD_SA to-azure
>> >>> generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi
>> >>> TSr N(EAP_ONLY) ]
>> >>> sending packet: from ss-public-ip[500] to azure-public-ip[500] (316 bytes)
>> >>> received packet: from azure-public-ip[500] to ss-public-ip[500] (68 bytes)
>> >>> parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
>> >>> received AUTHENTICATION_FAILED notify error
>> >>> establishing connection 'to-azure' failed
>> >>>
>> >>> conn to-azure
>> >>>         closeaction=clear
>> >>>         dpdaction=clear
>> >>>         ike=aes256-sha1-modp1024
>> >>>         esp=aes256-sha1
>> >>>         reauth=no
>> >>>         keyexchange=ikev2
>> >>>         mobike=no
>> >>>         ikelifetime=28800s
>> >>>         keylife=3600s
>> >>>         keyingtries=%forever
>> >>>         authby=secret
>> >>>         left=ss-public-ip
>> >>>         leftid=ss-public-ip
>> >>>         leftfirewall=no
>> >>>         leftsubnet=10.96.96.0/24
>> >>>         right=azure-public-ip
>> >>>         rightid=azure-public-ip
>> >>>         rightsubnet=10.96.97.0/24
>> >>>         auto=add
>> >>>
>> >>>
>> >>> I have made ipsec.conf based on the configuration examples provided by
>> >>> MS (for Juniper Dynamic routing ipsec). Local network behind SS is
>> >>> 10.96.96.0/24 and remote network in azure is 10.96.97.0/24. Strangely,
>> >>> azure generated example configs have 10.96.96.1/24. I tried with
>> >>> 10.96.96.1/24 as traffic selector too, but no difference.
>> >>>
>> >>> Any help is appreciated.
>> >>>
>> >>> Regards,
>> >>> Kimmo
>> >>>
>> >>>
>> >>>
>> >>> 2013/9/20 Martin Willi <martin at strongswan.org>:
>> >>>> Kimmo,
>> >>>>
>> >>>>> With that option, site-to-site connection is made with IKEv2 and PSK.
>> >>>>
>> >>>> Interesting.
>> >>>>
>> >>>>> Is there any way to connect Azure with Strongswan, using IKEv2 and this
>> >>>>> "dynamic routing VPN" option?
>> >>>>
>> >>>> According to the documentation, this looks like standard IKEv2 with PSK
>> >>>> authentication. I wouldn't expect any interoperability problems with
>> >>>> strongSwan.
>> >>>>
>> >>>> Regards
>> >>>> Martin
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Users mailing list
>> >>>> Users at lists.strongswan.org
>> >>>> https://lists.strongswan.org/mailman/listinfo/users
>>
>>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.21 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJSRHEwAAoJEDg5KY9j7GZY2XIP/jRTuRbfqUB/u9qeTzS8X+x4
> 9GHfUIy19ho2qiOqSheoZlqT22dKUc1ydVn7hI8ohehkkK3zeZdcDWr0dWrYLsia
> KdWxIFd7yCTqFYODN0AO6JtQzm8kERK5Z486vuksjwVJlizGnqALGIgKl8jxV2Zp
> ClYMC0efymNpdElzJ3ZjZ4BlHkNm5WQf0Laud6THxxWT+D6tSqztGLwpojL/DoDa
> IvMo79Fp4smbkTx8aMbkB77TrcoggdyWVf/traW1NBDgc9OFbfkf3QtNVpSUHC9r
> rJ3TuItZUKw4tp4xHBPHFe5scO8DXBGbEph1MncW7DBNLU5ivsUujrpwwxytaQ/P
> Vxu+9r/PIcCRF/Ctb2WdvoDaiqyZ6ODK4GGyC+ZoOi09vTIAT6tV1kFGtcfEMROl
> CezWhW+cjqQXuMnrFY7z6esfDrSnmy81gxP9flAp/p9/2AiAwOK4B4vWd7Zji9zw
> r+nGqA3N4zQ2344KJiTg7sPshtqAOkI6K8NBk79grfWKvekYljtnWRh30Xs8rLXM
> HJIQuHMQaEby/TYQ1Mh1GkxBSDG2knDkFZ7QEJi/KKo0ZjNIyEFJpqQZiUHF5CDE
> iit2o/4umhLxpXocF0qcQlxsQ9CY+11coEqysMVK9PRMOf22xUaZiGCAQivXQZ5V
> nXr5QXaQ3s4dLuBIfbNs
> =04Wl
> -----END PGP SIGNATURE-----
>




More information about the Users mailing list