<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 31, 2018 at 3:09 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 30 Mar 2018, Xinwei Hong wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Ping...<br>
</blockquote>
<br>
First let me say if you write an email on the 29th, and then try to<br>
demand an answer 1 day later, you are actually _reducing_ the chance<br>
of getting an answer. If you need next day support, you should look<br>
at commercial support. Please do not do this again.</blockquote><div><br></div><div>Sorry for doing that. I usually got help pretty quickly. So, I guess I was spoiled. :) </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Can anybody confirm the behavior? Or if I'm doing something wrong, I'd like to know.<br>
I see the similar behavior with racoon. But looks like Cisco is doing differently, according to this page. <a href="https://www.speaknetworks.com/what-is-ipsec-vpn-pfs-perfect-forward-secrecy/" rel="noreferrer" target="_blank">https://www.speaknetwork<wbr>s.com/what-is-ipsec-vpn-pfs-<wbr>perfect-forward-secrecy/</a><br>
</blockquote>
<br>
</span><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Thu, Mar 29, 2018 at 5:05 PM, Xinwei Hong <<a href="mailto:xhong@skytap.com" target="_blank">xhong@skytap.com</a>> wrote:<br>
Hi<br>
If we have pfsgroup in phase2alg, ipsec will use it in ESP, e.g.<br>
phase2alg=aes128-sha1;modp1536<br>
<br>
If we don't have it, e.g phase2alg=aes128-sha1, ipsec will use the DH group from phase 1 as pfsgroup.<br>
<br>
How do I tell ipsec to not use any pfsgroup? I tried "pfs=no", however, if the remote peer has pfsgroup, it will still accept the request. sound like it follows what the spec says:<br>
<br>
pfs<br>
<br>
whether Perfect Forward Secrecy of keys is desired on the connection*(Aqs keying channel (with PFS, penetration of the key-exchange protocol does not compromise keys negotiated<br>
earlier); Since there is no reason to ever refuse PFS, Libreswan will allow a connection defined with pfs=no to use PFS anyway. Acceptable values are yes (the default) and no.<br>
<br>
<br>
Also, if both ends have totally different pfsgroup, libreswan can establish connection between two peers and both side seems have different settings. <br>
<br>
Why it still works when both end mismatches? Do we need to care about pfsgroup at all? This is the case between two libreswan. When connecting to other VPN stack, mismatch<br>
sometimes does not work.<br>
</blockquote>
<br></span>
Be aware there is a difference between ikev1 and ikev2. In ikev1 the IKE<br>
SA is negotiated first, and then the ipsec is negotiated. In ikev2, the<br>
IKE and (first) IPsec SA is negotiated at the same time. This means that<br>
the first ipsec sa has the DH protection of the first (ike) pfs group.<br>
<br>
Therefor, in IKEv2, it makes little sense to specify different PFS for<br>
IKE and IPsec. So leave pfs=yes and only specify pfs in the ike= line,<br>
and you get the same pfs for the first ike/ipsec and any further ipsec<br>
sa's. If you have multiple ipsec sa's for one ike sa, you would never<br>
know which connection is brought up first (under the first pfs group) and<br>
which is brought up second (under the second pfs group). <b>Therefor,<br>
libreswan does not allow different pfs groups between ike/ipsec.</b></blockquote><div><br></div><div> I tried different algorithms in ike and esp. libreswan did not fail.,e.g. I have this in log:</div><div><br></div><div><div>000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16": IKE algorithms wanted: AES_CBC(7)_256-SHA1(2)-<b>MODP1024(2)</b></div><div>000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16": IKE algorithms found: AES_CBC(7)_256-SHA1(2)-MODP1024(2)</div><div>000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16": IKE algorithm newest: AES_CBC_256-SHA1-MODP1024</div><div>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)</div><div>000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16": ESP algorithms loaded: AES(12)_128-SHA1(2)</div><div>000 vpn-5653427: "conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16": ESP algorithm newest: AES_128-HMAC_SHA1; pfsgroup=<b>MODP1536</b></div></div><div><br></div><div>If I understand the log correctly, it shows different pfs/dh groups are used in ike/ipsec. Or do I misunderstand anything?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So the advise is to never specify the modp argument on the esp= line,<br>
which means use the same one as used for ike.<br></blockquote><div>I understand the advise. We sometime need support client using other VPN stack, so I want to understand how it goes when things mismatch.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
There is one exception in the upcoming 3.24 release to work around a<br>
Windows bug using the ms-dh-downgrade=yes option, which allows a<br>
different (weaker) modp group because the Windows bug causes a rekey<br>
to use the wrong group.<span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
Paul<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Thanks,</div><div class="gmail_extra">Xinwei</div></div>