<div dir="ltr">Hello, I am wondering if there are any ways it is possible to guarantee a tunnel with PFS using the 'default' keywords for both the <conn>.proposals and <conn>.children.<child>.esp_proposals fields within the swanctl.conf file. Is there another field which can be used to denote a requirement for PFS or some other way this can be achieved?<div><br></div><div>I am currently running strongswan 5.8.1. Currently I believe this is not possible as it appears the default ciphers include options without DH groups, though I am finding the default proposal source (src/libstrongswan/crypto/proposal/proposal.h/.c) a bit hard to follow (is there a documented list of these defaults available anywhere else?) My understanding is that the tunnel will achieve PFS if both tunnel endpoints support matching ciphers with a DH group however if not the fallback will be an alternative non-PFS cipher. However, my goal is to require PFS rather than enable PFS.</div><div><br></div><div>Would the easiest workaround for this requirement be to hardcode a subset of the default ciphers with DH groups into swanctl.conf?</div><div><br></div><div>As an additional clarification for perfect forward secrecy in general, the security recommendations page states that PFS can be achieved by using a DH group with ESP. Is it sufficient to declare an IKE cipher with a DH group and leave the ESP proposal to 'default', or does ESP still require a DH group explicitly in the proposal?</div><div><br></div><div>Alternatively, does it make any sense to leave the IKE cipher as 'default' while specifying an esp_proposal with a DH group? Under these circumstances it seems like we may run into a proposal mismatch during rekeying.</div><div><br></div><div>Thanks in advance for any advice anyone can provide!</div><div><br></div><div>Todd Cunningham</div><div><br></div></div>