[strongSwan] Windows 10 authenticating with certificate fails

Karl Denninger karl at denninger.net
Tue Jan 24 14:38:17 CET 2017

On 1/24/2017 06:59, Yudi V wrote:
> On Tue, Jan 24, 2017 at 11:35 PM, Karl Denninger <karl at denninger.net
> <mailto:karl at denninger.net>> wrote:
>     On 1/24/2017 04:12, Yudi V wrote:
>>     Hi Karl,
>>     Sorry about the delayed reply.
>>     I was finally able to use EAP-TLS, I think not having SAN same as
>>     CN on the client certificate caused it to fail. I cannot be 100%
>>     sure as I also had incorrect config to start with.
>>     I just got one more issue to sort out. How does the server decide
>>     which "conn" to use when a peer is trying to connect.
>>     when I try to connect from the windows client, I can connect to
>>     either rw_cert or rw_pw when one of them is commented out.  But
>>     if both of them are listed, then it always tries to use rw_pw
>>     (ie, eap-mschapv2) if it is listed before rw_cert.
>>     If I swap the order of rw_pw and rw_cert (listed before rw_pw)
>>     then it always tries to use eap-tls.
>>     I am guessing the information sent by the client to the server
>>     has some bearing on which "conn" to use.
>>     Is there anyway to dictate which "conn" should be used?
>>     My current config looks like below:
>>     conn %default
>>             keyexchange=ikev2
>>             dpdaction=clear
>>             dpddelay=300s
>>             left=%any
>>             leftsubnet=,::0 <,::0>
>>             leftauth=pubkey
>>             leftcert=serverCert.der       
>>             leftid=home1234.ddns.com <http://home1234.ddns.com>     
>>             leftfirewall=yes             
>>             lefthostaccess=yes           
>>             right=%any
>>             rightsourceip=%dhcp
>>             rightdns=
>>     conn rw_pw
>>             rightauth=eap-mschapv2         #using password
>>             eap_identity=%any
>>             auto=add
>>     conn rw_cert
>>             rightauth=eap-tls              #using certificate
>>             rightsendcert=never
>>             eap_identity=%any
>>             auto=add
>>     thanks!
>>     yudi
>     Whichever one it can match options with first.  If you have
>     multiple client types connecting you need to be careful what order
>     the various required options are listed in within the config file.
>     -- 
>     Karl Denninger
>     karl at denninger.net <mailto:karl at denninger.net>
>     /The Market Ticker/
>     /[S/MIME encrypted email preferred]/
>     _______________________________________________
>     Users mailing list
>     Users at lists.strongswan.org <mailto:Users at lists.strongswan.org>
>     https://lists.strongswan.org/mailman/listinfo/users
>     <https://lists.strongswan.org/mailman/listinfo/users>
> So order dictates which "Conn" is used, that cannot be right.
> I want to use the rightsourceip= setting to connect to different
> subnets using separate config sections. Local firewall block access
> between these subnets.
> -- 
> Kind regards,
> Yudi

The client and server negotiate the connection by exchanging options
(what the client and server can each support.)  The first match is found
for both in the config file is used.

I don't know if it's possible to tell Windows' client to *not* send the
flags stating that it "can" use MSCHAPv2, which would cause the server
to skip that config.  You'd think that if you set up a certificate
instead of a password it would not claim it will use something that's
not configured for a given connection but then again that would require
that the Windows client actually do intelligent things.  Given the
"issues" Windows has with CN and SAN, well....  :)

I have a "rightauth=pubkey" stanza in my config file since I also use
Strongswan's Android client to connect to the same server; they coexist
just fine.

conn WinUserCert

conn StrongSwan

Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170124/e331ef35/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2993 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170124/e331ef35/attachment.bin>

More information about the Users mailing list