[strongSwan] Azure dynamic routing VPN and Strongswan
Kimmo K
koippa at gmail.com
Thu Sep 26 20:25:50 CEST 2013
And now I was able to negotiate SA's just fine...
I re-generated PSK from azure and replaced the old one with it, it helped.
So, Strongswan 5.1.0 is able to negotiate IKEv2 tunnel to MS Azure
Dynamic Route VPN.
Regards,
Kimmo
2013/9/26 Kimmo K <koippa at gmail.com>:
> 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