Bug #4825
closed
Mobile client IPsec config omits peer identifier
100%
Description
The strongswan connection config generated for a mobile client association does not include the configured peer identifier (pattern). Therefor when using certificate authentication all certificates issued by the configured CA will be accepted instead of only the certificates matching the pattern.
Marking private as this might have severe security implications in some setups.
Updated by Chris Buechler over 9 years ago
- Assignee set to Chris Buechler
- Target version set to 2.2.4
Updated by Chris Buechler over 9 years ago
Looks like left/rightcertpolicy is the only option here. Generally a non-issue because people generate a CA just for IPsec.
Updated by Moritz Bechler over 9 years ago
I don't understand what you mean. The problem is that even though you configure a remote identifier, which e.g. might restrict the client certificates used to ones matching a special pattern, the generated configuration does not include that setting at all. This used to work correctly in <2.2.
For example we have have one CA for the certificates but two gateways, and one should only accept certificates having a certain OU. After upgrading any certificate will work for any gateway.
Updated by Chris Buechler over 9 years ago
Now I'm confused that I was looking at something different from what you were referring to. Could you share your 2.1.x config? Can email to cmb at pfsense dot org.
Updated by Moritz Bechler over 9 years ago
Don't have the 2.1 config around anymore, sorry. But I do not think it is necessary.
we have
/* Only specify peer ID if we are not dealing with a mobile PSK-only tunnel */
$peerid_spec = '';
if (!isset($ph1ent['mobile'])) {
whereas in 2.1 the condition was
if (!(($ph1ent['authentication_method'] == "pre_shared_key") && isset($ph1ent['mobile']))) {
and as far as I can see the condition simply does not do what is stated in the comment (I don't really understand the rationale for the mobile/PSK exclusion either, but that's not the point here). That results in no rightid generated at all for a mobile clients tunnel which is bad as some people rely on this.
Updated by Chris Buechler over 9 years ago
- Subject changed from Mobile client IPSec config ignores peer identifier to Mobile client IPsec config omits peer identifier
Thanks, I understand what you're saying now.
There's a reason things are the way they are - iOS and similar Cisco work-alike clients won't match rightid appropriately. All the IKEv1+PSK+Xauth strongswan example configs in their documentation omit rightid entirely. Searching for similar issues finds problems from others:
https://lists.strongswan.org/pipermail/users/2013-May/004645.html
https://lists.strongswan.org/pipermail/users/2012-December/004013.html
https://lists.strongswan.org/pipermail/users/2013-April/004540.html
2.1.5 skipped that for mobile PSK scenarios because each client has its own rightid that gets matched from the PSK tab entries or the PSKs in the user manager. That much is still correct.
The PSK+Xauth group matching issue needs to be pursued upstream with strongswan.
Looking at the RSA cases now.
Updated by Chris Buechler over 9 years ago
- Target version changed from 2.2.4 to 2.2.5
The RSA cases are no longer skipped, and work correctly now. Commits (didn't tag this ticket since it's private):
https://github.com/pfsense/pfsense/commit/6d86e659cff6086c95eb408be286203f0e80912f
https://github.com/pfsense/pfsense/commit/021a97b58a3ab24a66773ccc61670365015c85e5
The PSK ones need further investigation on why they don't match in strongswan, and reporting upstream. Moving this ticket to 2.2.5 as that's going to take a bit of time and we're otherwise ready for 2.2.4. The RSA circumstance in the original report is addressed, and probably the only one of potential real world security consequence.
Updated by Jim Thompson about 9 years ago
- Assignee changed from Chris Buechler to Matthew Smith
- Priority changed from Very High to Normal
Updated by Matthew Smith about 9 years ago
- Status changed from New to Feedback
This works in 2.2.4 and 2.2.5 for non-PSK authentication types.
Updated by Chris Buechler about 9 years ago
- Status changed from Feedback to Resolved
this is fine as is in 2.2.4 and newer.
Updated by