Mysql plugin stopped working for the newer versions.
I am running strongswan instance to connect with mobile clients. Had a working configuration with 5.6.3dr1 mysql and eap-mschap was operational flawlessly.
Even though I have the same configuration with 5.6.3 or 5.7.0
It results with failed mschapv2
15[IKE] initiating EAP_MSCHAPV2 method (id 0xE9) 15[ENC] generating IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ] 15[NET] sending packet: from 172.19.0.2 to 172.19.0.3 (112 bytes) 14[NET] received packet: from 172.19.0.3 to 172.19.0.2 (160 bytes) 14[ENC] parsed IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ] 14[IKE] EAP-MS-CHAPv2 verification failed, retry (1) 14[ENC] generating IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ] 14[NET] sending packet: from 172.19.0.2 to 172.19.0.3 (128 bytes) 06[NET] received packet: from 172.19.0.3 to 172.19.0.2 (80 bytes) 06[ENC] parsed INFORMATIONAL request 4 [ N(AUTH_FAILED) ] 06[ENC] generating INFORMATIONAL response 4 [ N(AUTH_FAILED) ] 06[NET] sending packet: from 172.19.0.2 to 172.19.0.3 (80 bytes) 06[IKE] IKE_SA ikev2-mschapv2-apple state change: CONNECTING => DESTROYING
Here is the working ipsec.conf and ipsec.secrets file os only containing : RSA privkey.pem. I am able to get this all working with correct mysql db identities & shared secrets. But not in newer versions.
config setup uniqueids=never charondebug = "ike 2, cfg 2" conn %default dpdaction=clear dpddelay=600s keyexchange=ikev2 auto=add rekey=no reauth=no fragmentation=yes compress=yes leftcert=fullchain.pem leftsendcert=always leftsubnet=0.0.0.0/0 ike=aes256gcm16-aes192gcm16-prfsha256-ecp256-ecp521,aes256-sha256-modp3072,chacha20poly1305-prfsha256-ntru256 esp=aes256gcm16-aes192gcm16-prfsha256-ecp256-modp3072,aes256-sha256-ecp256-modp3072,chacha20poly1305-ntru256 eap_identity=%identity rightsourceip=10.7.0.0/16 rightdns=126.96.36.199, 188.8.131.52 conn ikev2-mschapv2 rightauth=eap-mschapv2 conn ikev2-mschapv2-apple rightauth=eap-mschapv2 leftid=mysite.org
#1 Updated by Tobias Brunner 9 months ago
- Status changed from New to Feedback
I'm not sure this has anything to do with the mysql, sql or eap-mschapv2 plugin (there have been no changes to any of them since 5.6.3dr2). And if no password was found at all you'd get a different error message. Can you confirm that going back to 5.6.3dr2 fixes the problem?
The error message indicates that the two peers disagree on the calculated NT-Response. So this could also be a client issue. Did that change? Or was the password entered incorrectly?
#2 Updated by Yasin Bahtiyar 9 months ago
I used to build from https://download.strongswan.org/strongswan-5.6.3dr1.tar.bz2 which is not distributed any longer. I built 5.6.3dr1 from github tarball https://github.com/strongswan/strongswan/archive/5.6.3dr1.tar.gz following the hacking instructions and that build also failed mschap as in 5.7.0.
I am still able to get a working tunnel with the original build i have from tar.bz2 archive but I am unable to get it working with the new builds. The client is the same client for all of the working and failing versions above. and all codebases are configured with such options.
./configure --enable-silent-rules --prefix=/usr \ --sysconfdir=/etc \ --libexecdir=/usr/lib \ --with-ipsecdir=/usr/lib/strongswan \ --enable-aesni \ --enable-ccm \ --enable-chapoly \ --enable-cmd \ --enable-curl \ --enable-dhcp \ --enable-eap-identity \ --enable-eap-mschapv2 \ --enable-farp \ --enable-files \ --enable-gcm \ --enable-md4 \ --enable-newhope \ --enable-ntru \ --enable-sha3 \ --enable-shared \ --enable-sql \ --enable-mysql \ --enable-gmp \ --enable-rdrand \ --disable-aes \ --disable-ikev1 \ --disable-md5 \ --disable-rc2 \ --disable-sha1 \ --disable-static && \
#3 Updated by Tobias Brunner 9 months ago
that build also failed mschap as in 5.7.0.
I am still able to get a working tunnel with the original build i have from tar.bz2 archive
Do you still have that old source dir? Then compare it to that of the newly downloaded code for 5.6.3dr1. Except for newly generated files (keywords, parsers etc.) there shouldn't be any differences.
but I am unable to get it working with the new builds.
Which doesn't really make sense, unless you somehow patched the code that's working.
#4 Updated by Yasin Bahtiyar 9 months ago
I managed to get hold of of the 5.6.3dr1 archive in my build artefacts and tried to build it. And that one too failed. Then I noticed I am running my build pipeline on top of alpine:edge then quickly realised maybe mysql client libs are not behaving well. Managed to get 5.7.0 successfully establish a connection on alpine:3.7 with mariadb-client-libs. On 3.8 and edge mariadb-connector-c-3.0.3-r2 -> mariadb-connector-c-3.0.5-r0 version bump seems to lead to the failure discussed earlier. Apologies for taking your time. But mystery is solved for now at least for alpine 3.7. Thanks a lot!
#5 Updated by Tobias Brunner 9 months ago
Managed to get 5.7.0 successfully establish a connection on alpine:3.7 with mariadb-client-libs. On 3.8 and edge mariadb-connector-c-3.0.3-r2 -> mariadb-connector-c-3.0.5-r0 version bump seems to lead to the failure discussed earlier.
Thanks for the update. I wonder what changed in that library to cause this effect, and whether it's a bug or a feature change. It seems that either the wrong or corrupted data is returned from a query, which isn't good, if just an external library is updated.
#7 Updated by Yasin Bahtiyar 4 months ago
Trying to debug this and see what might be the root cause. Not sure if this is a mariadb-connector-c problem anymore.
eap_mschapv2.c:1125 is failing on my newer builds.
(gdb) x/24xb res->response.nt_response 0x55638519e242: 0xc8 0x3f 0x21 0x5f 0xad 0xe8 0xe9 0x92 0x55638519e24a: 0x48 0x3e 0xcf 0xc9 0x5f 0x58 0xed 0xb0 0x55638519e252: 0xbb 0xdc 0x67 0x2a 0x95 0x62 0xb4 0x72 (gdb) x/24xb this->nt_response.ptr 0x5563851a5d00: 0x3f 0x51 0x67 0x5d 0x5f 0x49 0x36 0xee 0x5563851a5d08: 0x1e 0x6e 0x42 0x42 0xc1 0x18 0xe3 0x88 0x5563851a5d10: 0x40 0x13 0x1d 0x56 0x0d 0xce 0x27 0xc2
Where in the older builds `memeq_const` returns true
(gdb) x/24b res->response.nt_response 0x56080f7deb82: 0x85 0x77 0xd4 0x6c 0x6a 0xb3 0x60 0x80 0x56080f7deb8a: 0x4d 0x09 0x97 0x35 0xa1 0x6d 0xf6 0x01 0x56080f7deb92: 0xe2 0x27 0xcb 0xb2 0x4c 0xd6 0xfa 0x3f (gdb) x/24b this->nt_response.ptr 0x56080f804940: 0x85 0x77 0xd4 0x6c 0x6a 0xb3 0x60 0x80 0x56080f804948: 0x4d 0x09 0x97 0x35 0xa1 0x6d 0xf6 0x01 0x56080f804950: 0xe2 0x27 0xcb 0xb2 0x4c 0xd6 0xfa 0x3f
Do you have any recommendations on how to debug this further?
#9 Updated by Yasin Bahtiyar 4 months ago
I had seen the issues you reported there earlier but not sure if I would be able to follow them up on my own. What I can probably try to do is build mariadb-connector-c from source and try to debug the library perhaps if that is the problem. Not sure how complex that would be but still. On the othar hand I am having hard time how is the
"SELECT s.type, s.data FROM shared_secrets AS s " "JOIN shared_secret_identity AS sm ON s.id = sm.shared_secret " "JOIN identities AS m ON sm.identity = m.id " "JOIN shared_secret_identity AS so ON s.id = so.shared_secret " "JOIN identities AS o ON so.identity = o.id " "WHERE m.type = ? AND m.data = ? AND o.type = ? AND o.data = ? " "AND (? OR s.type = ?)"
query results are utilized by eap_mschapv2 module. Would appreciate some high level explanation. How could I enumerate on the shared_enumerator_t within gdb? Would really appreciated if I could inspect what data is coming from mysql perhaps in this way.
#13 Updated by Noel Kuntze 22 days ago
- Status changed from Feedback to Closed
- Resolution set to No change required
Looks like it's fixed in C connector releases v3.1.0 and later.