Problem with establishing VPN connections with client

[Tony Zhou]

Hi Nikos,

SmoothConnect is based on Openconnect (as it claims), so I guess it 
behaves similarly... It prompts in client log after connected:
Connected (null) as 192.168.1.1+ipv6 addr, using SSL
Error: opening vpnc socket

while ocserv outputs:
Nov 15 01:15:24 hostname ocserv[2714]: [client.ip.addr]:53923 user 
'tony' of group 'tony' authenticated
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 User 
'tony' logged in
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 HTTP: 
Host: server.ip.addr
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 HTTP: 
User-Agent: Open AnyConnect VPN Agent v5.01-dirty
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 HTTP: 
Cookie: webvpn=somesecretcookie
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 HTTP: 
X-CSTP-Version: 1
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 HTTP: 
X-CSTP-Hostname: localhost
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 HTTP: 
X-CSTP-Accept-Encoding: deflate;q=1.0
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 HTTP: 
X-CSTP-Base-MTU: 1500
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 HTTP: 
X-CSTP-MTU: 1280
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 HTTP: 
X-CSTP-Address-Type: IPv6,IPv4
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 HTTP: 
X-DTLS-Master-Secret: somemastersecret
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 HTTP: 
X-DTLS-CipherSuite: AES256-SHA:AES128-SHA:DES-CBC3-SHA:DES-CBC-SHA
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 HTTP 
CONNECT /CSCOSSLC/tunnel
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 sending 
IPv4 192.168.1.1
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 sending 
IPv6 ipv6,addr
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 adding 
route 192.168.1.0/255.255.255.0
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 peer CSTP 
MTU is 1280
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 TCP MSS is 
1435
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 DTLS 
ciphersuite: AES128-SHA
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 suggesting 
DTLS MTU 1214
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 suggesting 
CSTP MTU 1214
Nov 15 01:15:24 hostname ocserv[2734]: [client.ip.addr]:53923 plaintext 
MTU is 1279
Nov 15 01:15:24 hostname ocserv[2714]: [client.ip.addr]:53923 setting 
ocvpn0 MTU to 1280
Nov 15 01:15:25 hostname ocserv[2714]: [main] DTLS record version: 1.0
Nov 15 01:15:25 hostname ocserv[2714]: [main] DTLS hello version: 1.0
Nov 15 01:15:25 hostname ocserv[2714]: [client.ip.addr]:53923 passed UDP 
socket
Nov 15 01:15:25 hostname ocserv[2734]: [client.ip.addr]:53923 TCP MSS is 
1435
Nov 15 01:15:25 hostname ocserv[2734]: [client.ip.addr]:53923 received 
new UDP fd and connected to peer
Nov 15 01:15:25 hostname ocserv[2734]: [client.ip.addr]:53923 setting up 
DTLS connection
Nov 15 01:15:25 hostname ocserv[2734]: [client.ip.addr]:53923 received 
-110 byte(s) (TLS)
Nov 15 01:15:25 hostname ocserv[2734]: GnuTLS error (at 
worker-vpn.c:1161): The TLS connection was non-properly terminated.

Nov 15 01:15:25 hostname ocserv[2714]: [client.ip.addr]:53923 command 
socket closed

And I do have

always-require-cert = false

and

user-profile = /etc/ocserv/profile.xml

enabled in ocserv conf file. The content of profile.xml: (grabbed from git)

<?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>
<CertEnrollmentPin>pinAllowed</CertEnrollmentPin>
                 <BackupServerList>
<HostAddress>server.ip.addr</HostAddress>
                 </BackupServerList>
         </ClientInitialization>

         <ServerList>
                 <HostEntry>
                     <HostName>VPN Server</HostName>
<HostAddress>server.ip.addr</HostAddress>
                 </HostEntry>
         </ServerList>
</AnyConnectProfile>



On 11/14/2013 10:41 AM, Nikos Mavrogiannopoulos wrote:
> On Thu, Nov 14, 2013 at 3:11 PM, Tony Zhou <tonytzhou at gmail.com> wrote:
>> Hi all,
>> I have problems making various clients connecting to the ocserv. So far none
>> of the clients are able to successfully make a VPN connection. Platform:
>> Debian 7, ocserv 2.1
>>
>> Tried with Android (Anyconnect ICS+), it can successfully authenticate, but
>> after accepting the banner client will prompt "The required license for this
>> type of VPN client is not available on the secure gateway. Please contact
>> your network administrator." I guess it's just Cisco does not like the idea
>> of 3rd party server that can accept Anyconnect Client connections? ;-) Fair
>> enough. Here's the log:
> I've noticed that too about the client. As I understood one would need
> to add some cisco license into the server headers so a solution is
> probably impossible.
> However you may want to try Kevin's android client which is based on
> openconnect:
> https://github.com/cernekee/ics-openvpn
>
>
>> Somehow it started authentication, but immediately closed the socket and
>> deinited.
>> Tried with some other clients, including SmoothConnect (Android 3rd party
>> client connecting to Cisco ASA) and HP webOS, but none of them works. Don't
>> have the log at hand at this moment...
>> Any suggestions will be appreciated.
> Did you enable the specific options for anyconnect in the configuration file?
> The anyconnect clients download some special policy etc files from the
> server that may not have been there in ocserv. Unfortunately they much
> differ on the requests they make on every version. You may want to
> check the client's log as well for clues of what failed.
>
> regards,
> Nikos