Juniper’s Network Connect ncsvc on Linux: “host checker failed, error 10”
- by hfs
I’m trying to log in to a Juniper VPN with Network Connect from a headless Linux client. I followed the instructions and used the script from http://mad-scientist.us/juniper.html. When running the script with --nogui switch the command that gets finally executed is $HOME/.juniper_networks/network_connect/ncsvc -h HOST -u USER -r REALM -f $HOME/.vpn.default.crt. I get asked for the password, a line “Connecting to…” is printed but then the programm silently stops. When adding -L 5 (most verbose logging) to the command line, these are the last messages printed to the log:
dsclient.info state: kStateCacheCleaner (dsclient.cpp:280)
dsclient.info --> POST /dana-na/cc/ccupdate.cgi (authenticate.cpp:162)
http_connection.para Entering state_start_connection (http_connection.cpp:282)
http_connection.para Entering state_continue_connection (http_connection.cpp:299)
http_connection.para Entering state_ssl_connect (http_connection.cpp:468)
dsssl.para SSL connect ssl=0x833e568/sd=4 connection using cipher RC4-MD5 (DSSSLSock.cpp:656)
http_connection.para Returning DSHTTP_COMPLETE from state_ssl_connect (http_connection.cpp:476)
DSHttp.debug state_reading_response_body - copying 0 buffered bytes (http_requester.cpp:800)
DSHttp.debug state_reading_response_body - recv'd 0 bytes data (http_requester.cpp:833)
dsclient.info <-- 200 (authenticate.cpp:194)
dsclient.error state host checker failed, error 10 (dsclient.cpp:282)
ncapp.error Failed to authenticate with IVE. Error 10 (ncsvc.cpp:197)
dsncuiapi.para DsNcUiApi::~DsNcUiApi (dsncuiapi.cpp:72)
What does host checker failed mean? How can I find out what it tried to check and what failed? The HostChecker Configuration Guide mentions that a $HOME/.juniper_networks/tncc.jar gets installed on Linux, but my installation contains no such file. From that I concluded that HostChecker is disabled for my VPN on Linux? Are the POST to /dana-na/cc/ccupdate.cgi and “host checker failed” connected or independent? By running the connection over a SSL proxy I found out that the POST data is status=NOTOK (Funny side note: the client of the oh-so-secure VPN does not validate the server’s SSL certificate, so is wide open to MITM attacks…). So it seems that it’s the client that closes the connection and not the server.