Bug #12053
closedPRF Algorithm is Always Set to SHA256 on New Tunnel Creations
0%
Description
When creating new P1s regardless of what the hash algorithm is set to the variable in config.xml is always set to <prf-algorithm>sha256</prf-algorithm>. This also seems to make its way into swanctl.conf in certain situations as well. A customer upgrading from 2.4.5p1 had 3DES set for this variable for a P1 tunnel on one endpoint, but did not have the "PRF Selection" checkbox selected in the P1 Advanced Config. The variable for <prf-algorithm> was loaded into swanctl and was causing issues with another pfSense endpoint until the PRF algorithm was manually set to match the other endpoint.
Updated by Kris Phillips almost 3 years ago
Reference internal ticket INC-87329 for troubleshooting steps with customer that experienced this.
Updated by Kris Phillips almost 3 years ago
Selection feature was introduced in changeset f5ddbec114b3b9ecce14761d173381556422061b
Updated by Jim Pingle almost 3 years ago
- Status changed from New to Feedback
I can't reproduce this here. I see the config.xml tag <prf-algorithm>sha256</prf-algorithm>
but it does not get put into swanctl.conf
.
The code already checks the value of the other conditional setting:
if ($ph1ent['prfselect_enable'] != 'yes') {
$p1enc['prf-algorithm'] = false;
}
My tunnel config has:
<encryption>
<item>
<encryption-algorithm>
<name>aes128gcm</name>
<keylen>128</keylen>
</encryption-algorithm>
<hash-algorithm>aesxcbc</hash-algorithm>
<prf-algorithm>sha256</prf-algorithm>
<dhgroup>14</dhgroup>
</item>
</encryption>
And in the resulting swanctl.conf
there is no -prf<algo>
string in the P1 proposal:
proposals = aes128gcm128-aesxcbc-modp2048
So if you can reproduce the condition where it is interfering, we will need to see more of the problem configuration.
If the problem exists as you state, the proposal would look like this:
proposals = aes128gcm128-aesxcbc-prfsha256-modp2048
But the only way I can get that result is to check the PRF Selection box in P1.
If I check it the PRF is used, if I uncheck it the PRF is ignored, which is exactly the expected behavior.
Updated by Kris Phillips almost 3 years ago
I've only been able to reproduce this after further testing on the one user's install. Not sure how this was triggered there, but it must be an extremely rare condition. This can likely be closed out unless we can find out how it was replicated.
Updated by Jim Pingle almost 3 years ago
- Status changed from Feedback to Closed
OK, if we can find a way to reproduce it on another system, we can always reopen it later with the exact conditions and procedure.