[Swan] question about pfsgroup

Xinwei Hong xhong at skytap.com
Mon Apr 2 20:32:50 UTC 2018


Hi Paul,

I'm still using libreswan 3.20. Both ends are using default ikev2=permit.
So, ikev1 is used in my test cases. What I observed is that VPN still works
even when pfsgroup does not match. (either no pfsgroup, or different group
value).

I feel sometime it's hard to determine from log what pfsgroup it's actually
using. If I see this:
Apr  2 20:17:53 vvr-10-69-244-19 pluto[10391]: vpn-5653427:
"conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16" #377:
initiating Quick Mode
PSK+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO
to replace #376 {using isakmp#4 msgid:9a47d103 proposal=3DES(3)_000-SHA1(2)
*pfsgroup=MODP1024*}

does it mean that modp1024 is used?

When I specify "pfs=no", at first it will have:
Apr  2 20:23:27 vvr-10-69-244-19 pluto[18354]: vpn-5653427:
"conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16" #2:
initiating Quick Mode
PSK+ENCRYPT+TUNNEL+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO
{using isakmp#1 msgid:de62bfd4 proposal=3DES(3)_000-SHA1(2)
*pfsgroup=no-pfs*}

when it rekeys later(set to expire after 1 minute), it shows
Apr  2 20:24:13 vvr-10-69-244-19 pluto[18354]: vpn-5653427:
"conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16" #5:
initiating Quick Mode
PSK+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO
to replace #3 {using isakmp#4 msgid:38e9b07b proposal=3DES(3)_000-SHA1(2)
*pfsgroup=MODP1024*}

what should I trust to find out the pfsgroup in use?

At the same time, the other is actually racoon and have "pfs_group
modp1536;". Seems mismatches do not affect either part.

Thanks,
Xinwei







On Sun, Apr 1, 2018 at 9:11 AM, Paul Wouters <paul at nohats.ca> wrote:

> On Sat, 31 Mar 2018, Xinwei Hong wrote:
>
>  I tried different algorithms in ike and esp.  libreswan did not
>> fail.,e.g. I have this in log:
>>
>> 000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-
>> 10.30.0.0/16":   IKE algorithms wanted: AES_CBC(7)_256-SHA1(2)-MODP102
>> 4(2)
>> 000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-
>> 10.30.0.0/16":   IKE algorithms found:  AES_CBC(7)_256-SHA1(2)-MODP102
>> 4(2)
>> 000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-
>> 10.30.0.0/16":   IKE algorithm newest: AES_CBC_256-SHA1-MODP1024
>> 000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-
>> 10.30.0.0/16":   ESP algorithms wanted: AES(12)_128-SHA1(2);
>> pfsgroup=MODP1536(5)
>> 000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-
>> 10.30.0.0/16":   ESP algorithms loaded: AES(12)_128-SHA1(2)
>> 000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-
>> 10.30.0.0/16":   ESP algorithm newest: AES_128-HMAC_SHA1;
>> pfsgroup=MODP1536
>>
>> If I understand the log correctly, it shows different pfs/dh groups are
>> used in ike/ipsec. Or do I misunderstand anything?
>>
>
> I think code is a little in flux too with Andrew's recent changes to
> support the microsoft rekey DH workaround code.
>
> I just tested:
>
>         ike=aes128-sha1-modp2048
>         esp=aes128-sha1-modp1536
>
> which seems to result in:
>
> 000 "westnet-eastnet-ikev2":   IKEv2 algorithm newest:
> AES_CBC_128-HMAC_SHA1-MODP2048
> 000 "westnet-eastnet-ikev2":   ESP algorithm newest:
> AES_CBC_128-HMAC_SHA1_96; pfsgroup=MODP1536
>
> However, looking at the logs, since the first child sa transforms don't
> include a DH group, it was really doing this as modp2048 from the ike
> group. However, rerunning the --up command, which triggers and IPsec
> rekey event, showed it did in fact use modp1536 for the rekey. So the
> display information on the first child sa in the status command seems
> to be misleading.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20180402/0b237196/attachment.html>


More information about the Swan mailing list