Project

General

Profile

Bug #1044

SQL looking for peer configs matching [%any]

Added by IT Development over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Category:
libcharon
Target version:
Start date:
27.07.2015
Due date:
Estimated time:
Affected version:
5.3.2
Resolution:
Fixed

Description

Hi,

We are using the MySQL Database backend with StrongSwan, we have one problem that we can't seem to figure out and would appreciate any guidance on how to resolve this.

In the peer_configs table there is a column called "local_id", when we set this to value 6 (which in our set up is "%any" from the identities table) we get a successful connection, however as soon as we change it to the server's FQDN or DN in the certificate, the connection fails authentication.

We suspect the problem is associated with the following line in the Log:

charon: 08[CFG] looking for peer configs matching 192.168.0.1[%any]...1.1.1.1[C=GB, O=CompanyName, CN=]
charon: 08[CFG] no matching peer config found

We believe the issue lies with the fact strongswan looks for a peer config matching to "%any" on the server side.

How can we change it in the database so that it looks for the FQDN or DN of the certificate instead?

For example: looking for peer configs matching 192.168.0.1[server.example.com]...1.1.1.1[C=GB, O=CompanyName, CN=]
Or: looking for peer configs matching 192.168.0.1[C=GB, O=CompanyName, CN=server.example.com]...1.1.1.1[C=GB, O=CompanyName, CN=]

Thanks for any help in advance.


Related issues

Related to Issue #1036: MySQL configurationClosed17.07.2015

Associated revisions

Revision 6927d622 (diff)
Added by Tobias Brunner over 5 years ago

sql: Also do a reversed ID match

This is required for the case where IDr is not sent (i.e. is %any).
The backend manager does the same.

Fixes #1044.

History

#1 Updated by Tobias Brunner over 5 years ago

#2 Updated by Tobias Brunner over 5 years ago

  • Status changed from New to Feedback
  • Priority changed from High to Normal

How can we change it in the database so that it looks for the FQDN or DN of the certificate instead?

That depends on the remote ID sent by the client (IDr payload), in this case it probably didn't send one.

But %any should really match any ID in the database, however, the matching in the SQL plugin seems a bit too restrictive. In particular the case where IDr is %any is not handled properly. What's missing is a reverse match. Please try if the patch in the sql-id-match branch fixes the issue.

#3 Updated by IT Development over 5 years ago

Hi Tobias,

The patch has worked, thank you very much.

We are using the StrongSwan Android Client to make the connection, therefore I assume that is sending the IDr as %any. I can't seem to find any way to specify this within the StrongSwan Android Client?

On another note, we had rightauth=pubkey defined in ipsec.conf, we would like to specify this setting in the database instead, where exactly do we do this?

Thanks

#4 Updated by Tobias Brunner over 5 years ago

  • Tracker changed from Issue to Bug
  • Target version set to 5.3.3
  • % Done set to 0

The patch has worked, thank you very much.

OK, thanks for testing.

We are using the StrongSwan Android Client to make the connection, therefore I assume that is sending the IDr as %any. I can't seem to find any way to specify this within the StrongSwan Android Client?

The Android app uses the hostname/IP of the gateway as configured in the profile as remote identity, but it does not actually send it to the responder as IDr payload (so you get %any on the server). This allows the server to e.g. use a DN as identity, which would otherwise not match the client's IDr. The client will later verify the identity against all subjectAltName extensions of the server certificate.

On another note, we had rightauth=pubkey defined in ipsec.conf, we would like to specify this setting in the database instead, where exactly do we do this?

This can't be specified via SQL currently. The auth_method column in the peer_configs table defines only leftauth (however a bit limited, as e.g. no EAP method can be defined, which, on the other hand, is possible for rightauth see below).

rightauth is basically set to any (so the client is free to use pubkey authentication). It is possible, though, to enforce a specific EAP method for the remote authentication via the eap_type column (this corresponds to rightauth=eap-<method>).

#5 Updated by Tobias Brunner over 5 years ago

  • Category set to libcharon
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to Fixed

Also available in: Atom PDF