According to the achieved post http://lists.infradead.org/pipermail/openconnect-devel/2014-October/002303.html I found my server had two IPs, and the source IP of the "Server Hello" is not the same as the destination IP of the "Client Hello". After chaning the server IP, now the "DTLS handshake failed" problem with OpenConnect-GUI is gone. As for ACSMC, it still doesn't work after upgrading to v4.0. Regards, tefeng On 2015/1/10 1:39, tefeng wrote: > I've restored 'profile.xml' to the sample: > > <?xml version="1.0" encoding="UTF-8"?> > <AnyConnectProfile xmlns="http://schemas.xmlsoap.org/encoding/"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://schemas.xmlsoap.org/encoding/ > AnyConnectProfile.xsd"> > > <ClientInitialization> > <UseStartBeforeLogon > UserControllable="false">false</UseStartBeforeLogon> > <StrictCertificateTrust>false</StrictCertificateTrust> > <RestrictPreferenceCaching>false</RestrictPreferenceCaching> > <RestrictTunnelProtocols>IPSec</RestrictTunnelProtocols> > <BypassDownloader>true</BypassDownloader> > <WindowsVPNEstablishment>AllowRemoteUsers</WindowsVPNEstablishment> > <CertEnrollmentPin>pinAllowed</CertEnrollmentPin> > <CertificateMatch> > <KeyUsage> > <MatchKey>Digital_Signature</MatchKey> > </KeyUsage> > <ExtendedKeyUsage> > <ExtendedMatchKey>ClientAuth</ExtendedMatchKey> > </ExtendedKeyUsage> > </CertificateMatch> > > <BackupServerList> > <HostAddress>localhost</HostAddress> > </BackupServerList> > </ClientInitialization> > > <ServerList> > <HostEntry> > <HostName>VPN Server</HostName> > <HostAddress>localhost</HostAddress> > </HostEntry> > </ServerList> > </AnyConnectProfile> > > After I copied the client certificate from "Trusted Root Certification > Authorities" to "Personal" in MMC window on win7, the certificate was > recognized by ACSMC. > > But the ACSMC adapter couldn't get an IP while ACSMC was prompting > "Establishing VPN - Repairing VPN adapter..", and finally the > connection failed. > > ###### log ####### > ... > ocserv[5896]: worker: *.*.*.*:58131 adding custom header 'X-DTLS-MTU: > 1200' > ocserv[5858]: worker: *.*.*.*:58109 adding custom header 'X-CSTP-MTU: > 1200' > ocserv[5858]: worker: *.*.*.*:58109 peer's base MTU is 1500 > ocserv[5858]: worker: *.*.*.*:58109 TCP MSS is 1439 > ocserv[5858]: worker: *.*.*.*:58109 reducing MTU due to TCP MSS to 1439 > ocserv[5858]: worker: *.*.*.*:58109 CSTP Base MTU is 1439 bytes > ocserv[5858]: worker: *.*.*.*:58109 DTLS ciphersuite: AES128-SHA > ocserv[5858]: worker: *.*.*.*:58109 DTLS overhead is 94 > ocserv[5858]: worker: *.*.*.*:58109 suggesting DTLS MTU 1345 > > ocserv[5858]: worker: *.*.*.*:58109 setsockopt(SO_PRIORITY) to 5, failed. > > ocserv[5858]: worker: *.*.*.*:58109 sending message 'tun mtu change' > to main > ocserv[5845]: main: *.*.*.*:58109 main received message 'tun mtu > change' of 3 bytes > ocserv[5845]: main: *.*.*.*:58109 setting vpns0 MTU to 1345 > ocserv[5858]: worker: *.*.*.*:58109 setting MTU to 1345 > ocserv[5858]: worker: *.*.*.*:58109 sending message 'session info' to > main > ocserv[5845]: main: *.*.*.*:58109 main received message 'session info' > of 88 bytes > > ocserv[5858]: worker: *.*.*.*:58109 received BYE packet; exiting > > ocserv[5858]: worker: *.*.*.*:58109 sending message 'cli stats' to main > ocserv[5858]: worker: *.*.*.*:58109 sending stats (in: 0, out: 0) to main > ocserv[5845]: main: *.*.*.*:58109 main received message 'cli stats' of > 4 bytes > ocserv[5845]: main: *.*.*.*:58109 main-misc.c:426: command socket closed > ocserv[5845]: main: *.*.*.*:58109 removing client '' with id '5858' > ocserv[5845]: main: putting process 5874 to cgroup 'cpuset:test' > ocserv[5845]: main: main-misc.c:755: cannot open: > /sys/fs/cgroup/cpuset/test/tasks > ocserv[5874]: worker: *.*.*.*:58117 accepted connection > ocserv[5874]: worker: *.*.*.*:58117 sending message 'resume data fetch > request' to main > ocserv[5845]: main: *.*.*.*:58117 main received message 'resume data > fetch request' of 34 bytes > ocserv[5845]: main: *.*.*.*:58117 TLS session DB resuming > 4c9eebb934d897503f9657a1b13f1d7e2a154f72e66d8245e4fad8b97485a57e > ocserv[5845]: main: *.*.*.*:58117 sending message 'resume data fetch > reply' to worker > ocserv[5874]: worker: *.*.*.*:58117 client certificate verification > succeeded > ocserv[5874]: worker: *.*.*.*:58117 TLS handshake completed > ocserv[5874]: worker: *.*.*.*:58117 User-agent: 'AnyConnect Windows > 3.1.06073' > ocserv[5845]: main: *.*.*.*:58117 main-misc.c:426: command socket closed > ocserv[5845]: main: *.*.*.*:58117 removing client '' with id '5874' > ##### END ##### > > regards, > tefeng > > > > On 2015/1/9 23:05, tefeng wrote: >> Thanks for your quick reply. >> >> The 'profile.xml' was copied from the sample directory 'doc' without >> any changes. This time I modified it on server side as you >> demonstrated, and also added custom OID value in client certificate's >> "Properties - Extended Validation" dialog on win7. But it still >> doesn't work with same error in log file. >> >> Then I tried 'openconnect-gui' and selected the client certificate in >> setting windows. It seems OK except for the repeated prompt "DTLS >> handshake failed: Resource temporarily unavailble, try again". Thanks. >> >> regards, >> tefeng >> >> >> On 2015/1/9 21:00, David Woodhouse wrote: >>> On Fri, 2015-01-09 at 20:54 +0800, tefeng wrote: >>>> It seemed that ACSMC on win7 didn't recognize the certificate >>>> (imported >>>> via 'mmc' command, the same way for strongSwan certificate which >>>> works OK). >>>> >>>> Any recommendations would be really appreciated. Thanks in adv. >>> Were you looking for recommendations other than using OpenConnect on >>> Windows? https://github.com/openconnect/openconnect-gui/wiki >>> >>> How does the Cisco client know which certificate to use? In the profile >>> there is a <CertificateMatch> node which looks something like this: >>> >>> <CertificateMatch> >>> <KeyUsage> >>> <MatchKey>Digital_Signature</MatchKey> >>> </KeyUsage> >>> <ExtendedKeyUsage> >>> <ExtendedMatchKey>ClientAuth</ExtendedMatchKey> >>> <CustomExtendedMatchKey>1.2.840.113741.1.5.1.101.1.5</CustomExtendedMatchKey> >>> >>> </ExtendedKeyUsage> >>> </CertificateMatch> >>> >>> Do you have something similar in your profile, and does the certificate >>> you've imported match the criteria? >>> >> >
