[Swan] RHEL7 Libreswan -> Google Cloud VPN

Patrick Bakker patrick at vanbelle.com
Thu Aug 27 15:13:41 UTC 2015


I've been looking through the Google Cloud VPN documentation (
https://cloud.google.com/compute/docs/vpn) and there is some confusing
terminology here:

Near the top it says:
"Compute Engine VPN uses ESP in Tunnel mode with authentication. AH and ESP
in Transport mode are not supported."

But under the heading "Set up the Peer VPN gateway" it then says:
"IPsec Mode: ESP+Auth Tunnel mode"

Is "ESP in Tunnel mode" the same thing as "ESP+Auth Tunnel mode"?


On Thu, Aug 27, 2015 at 7:49 AM, Patrick Bakker <patrick at vanbelle.com>
wrote:

> Thanks for your suggestions Paul!
>
> The bottom suggestion:
>
>         ikev2=insist
>         ike=aes_gcm128-sha2
>         esp=aes_gcm128-null
>
> got me to a different message:
>
> sending unencrypted notification v2N_NO_PROPOSAL_CHOSEN to y.y.y.y:500
> initial parent SA message received on x.x.x.x:500 but no connection has
> been authorized with policy=IKEV2_ALLOW
>
> Changing the last line to esp=aes_gcm128-sha1 results in the same log
> message.
>
>
> On Thu, Aug 27, 2015 at 6:34 AM, Paul Wouters <paul at nohats.ca> wrote:
>
>> On Wed, 26 Aug 2015, Patrick Bakker wrote:
>>
>> I'm trying to setup a VPN between RHEL7 and Google Cloud VPN. I keep
>>> getting this cryptic error:
>>>
>>> "google-tunnel" #6: ignored CCM/GCM ESP proposal 1: integrity transform
>>> must be IKEv2_AUTH_NONE or absent
>>>  ikev2_parent_inI2outR2_tail returned STF_FAIL with
>>> v2N_NO_PROPOSAL_CHOSEN"
>>>
>>
>> It seems they are proposing AES_GCM which is an AEAD ciper, meaning that
>> it should not use an integrity algorithm. In libreswan configuration
>> terms this means:
>>
>>         esp=aes_gcm128-null
>>
>> what they seem to be doing (without seeing the debug logs) look like:
>>
>>         esp=aes_gcm128-sha1
>>
>> This is with a barebones configuration like:
>>> conn google-tunnel
>>>         authby=secret
>>>         auto=start
>>>         type=tunnel
>>>         left=x.x.x.x
>>>         leftid=x.x.x.x
>>>         leftsourceip=x.x.x.x
>>>         leftsubnet=x.x.x.x/24
>>>         right=y.y.y.y
>>>         rightsubnet=y.y.y.y/16
>>>         rightsourceip=y.y.y.y
>>>
>>> As well as if I try to force some algorithm like:
>>>         ike=aes-sha1
>>>         ikev2=insist
>>>         phase2=esp
>>>         phase2alg=aes_gcm_c-128-null
>>>
>>
>> What happens if you insist on not using GCM? eg
>>
>>         esp=aes128-sha2
>>
>> Anybody have any ideas?
>>>
>>
>> It seems like a bug in their implementation. You can try and use
>> IKEv2 to see if that works around the bug:
>>
>>         ikev2=insist
>>
>> When using IKEv2, you can also use aes_gcm for ike with libreswan, so
>> then you can also try:
>>
>>         ikev2=insist
>>         ike=aes_gcm128-sha2
>>         esp=aes_gcm128-null
>>
>> Note that here the "sha2" on the ike line means the prf, not the
>> auth/integ algorithm.
>>
>> If any of these hints help, please let me know so we can contact
>> google and write up a FAQ/interop issue on this.
>>
>> Paul
>>
>
>
>
> --
> Patrick Bakker
> *IT Manager*
> Van Belle Nursery | vanbelle.com <http://www.vanbelle.com/>
> T: 1-888-826-2355 | F: 604-853-6282
>
> Find us on Facebook <http://facebook.com/vanbellenursery> • Twitter
> <http://twitter.com/vanbellenursery> • Google+
> <http://gplus.to/vanbellenursery>
>



-- 
Patrick Bakker
*IT Manager*
Van Belle Nursery | vanbelle.com <http://www.vanbelle.com/>
T: 1-888-826-2355 | F: 604-853-6282

Find us on Facebook <http://facebook.com/vanbellenursery> • Twitter
<http://twitter.com/vanbellenursery> • Google+
<http://gplus.to/vanbellenursery>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20150827/27d27de0/attachment-0001.html>


More information about the Swan mailing list