Added by Chris Buechler almost 11 years ago. Updated almost 11 years ago.
100%
Description
iOS PSK mismatches are happening in some cases. Going back to pre-2.2.4 behavior works, done here. https://github.com/pfsense/pfsense/commit/41d968bd163112361c86d077bec8a4cd59dd6828
Needs additional review.
I'm assigning this to Matt, and putting it back in Confirmed, so he can weigh-in.
Chris Buechler wrote:
iOS PSK mismatches are happening in some cases. Going back to pre-2.2.4 behavior works, done here. https://github.com/pfsense/pfsense/commit/41d968bd163112361c86d077bec8a4cd59dd6828
Needs additional review.
Under what conditions are PSK mismatches occurring? What version of IKE is being used and which authentication method (mutual psk, mutual psk with xauth, or eap-mschapv2) when this happens?
Thread where issue is discussed for reference:
https://forum.pfsense.org/index.php?topic=97530.0
Matthew Smith wrote:
Under what conditions are PSK mismatches occurring? What version of IKE is being used and which authentication method (mutual psk, mutual psk with xauth, or eap-mschapv2) when this happens?
We've discussed via email since then, but to add here: IKEv1 mutual PSK, with and without xauth. There's something more to it than just that though.
This is fine. According to this document https://wiki.strongswan.org/projects/strongswan/wiki/IpsecSecrets you cannot match an IKEv1 PSK connection against any ID's other than the IP address of the client when selecting the PSK to use. That is a value that is typically not known for mobile IPSec so it is reasonable to not specify ID's for PSK.
That's true of main mode only, as aggressive sends the ID in the clear, but agree that this is fine now. The group doesn't get matched anyway when it is there.
Also available in: Atom