<div dir="ltr">Hi Paul,<div><br></div><div>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). </div><div><br></div><div>I feel sometime it's hard to determine from log what pfsgroup it's actually using. If I see this:</div><div>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) <b>pfsgroup=MODP1024</b>}<br></div><div><br></div><div>does it mean that modp1024 is used?</div><div><br></div><div>When I specify "pfs=no", at first it will have:</div><div>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) <b>pfsgroup=no-pfs</b>}<br></div><div><br></div><div>when it rekeys later(set to expire after 1 minute), it shows</div><div>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) <b>pfsgroup=MODP1024</b>}<br></div><div><br></div><div>what should I trust to find out the pfsgroup in use? </div><div><br></div><div>At the same time, the other is actually racoon and have "pfs_group modp1536;". Seems mismatches do not affect either part.</div><div><br></div><div>Thanks,</div><div>Xinwei</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 1, 2018 at 9:11 AM, Paul Wouters <span dir="ltr"><<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, 31 Mar 2018, Xinwei Hong wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I tried different algorithms in ike and esp. libreswan did not fail.,e.g. I have this in log:<br>
<br>
000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRe<wbr>moteRoutedSubnet-tunnel-<a href="http://10.30.0.0/16" target="_blank">10.30.<wbr>0.0/16</a>": IKE algorithms wanted: AES_CBC(7)_256-SHA1(2)-MODP102<wbr>4(2)<br>
000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRe<wbr>moteRoutedSubnet-tunnel-<a href="http://10.30.0.0/16" target="_blank">10.30.<wbr>0.0/16</a>": IKE algorithms found: AES_CBC(7)_256-SHA1(2)-MODP102<wbr>4(2)<br>
000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRe<wbr>moteRoutedSubnet-tunnel-<a href="http://10.30.0.0/16" target="_blank">10.30.<wbr>0.0/16</a>": IKE algorithm newest: AES_CBC_256-SHA1-MODP1024<br>
000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRe<wbr>moteRoutedSubnet-tunnel-<a href="http://10.30.0.0/16" target="_blank">10.30.<wbr>0.0/16</a>": ESP algorithms wanted: AES(12)_128-SHA1(2); pfsgroup=MODP1536(5)<br>
000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRe<wbr>moteRoutedSubnet-tunnel-<a href="http://10.30.0.0/16" target="_blank">10.30.<wbr>0.0/16</a>": ESP algorithms loaded: AES(12)_128-SHA1(2)<br>
000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRe<wbr>moteRoutedSubnet-tunnel-<a href="http://10.30.0.0/16" target="_blank">10.30.<wbr>0.0/16</a>": ESP algorithm newest: AES_128-HMAC_SHA1; pfsgroup=MODP1536<br>
<br>
If I understand the log correctly, it shows different pfs/dh groups are used in ike/ipsec. Or do I misunderstand anything?<br>
</blockquote>
<br></span>
I think code is a little in flux too with Andrew's recent changes to<br>
support the microsoft rekey DH workaround code.<br>
<br>
I just tested:<br>
<br>
ike=aes128-sha1-modp2048<br>
esp=aes128-sha1-modp1536<br>
<br>
which seems to result in:<br>
<br>
000 "westnet-eastnet-ikev2": IKEv2 algorithm newest: AES_CBC_128-HMAC_SHA1-MODP2048<br>
000 "westnet-eastnet-ikev2": ESP algorithm newest: AES_CBC_128-HMAC_SHA1_96; pfsgroup=MODP1536<br>
<br>
However, looking at the logs, since the first child sa transforms don't<br>
include a DH group, it was really doing this as modp2048 from the ike<br>
group. However, rerunning the --up command, which triggers and IPsec<br>
rekey event, showed it did in fact use modp1536 for the rekey. So the<br>
display information on the first child sa in the status command seems<br>
to be misleading.<span class="HOEnZb"><font color="#888888"><br>
<br>
Paul<br>
</font></span></blockquote></div><br></div>