Thanks very much for taking the time to look into this. Yes, I get the exact same result with 7.08 and with v7.08-125- g31b5c4a. Here is the output you requested: Attempting to connect to server xxx.xxx.xxx.xxx:443 Connected to xxx.xxx.xxx.xxx:443 Using certificate file /home/*********** Using client certificate '/CN=********' SSL negotiation with *** Matched peer certificate subject name '***' Connected to HTTPS on *** Got HTTP response: HTTP/1.1 200 OK Content-type: application/octet-stream Pragma: no-cache NCP-Version: 3 Set-Cookie: DSLastAccess=1535592203; path=/; Secure Connection: close X-Frame-Options: SAMEORIGIN Strict-Transport-Security: max-age=31536000 > 0000: 16 00 00 04 00 00 00 09 00 62 6c 69 6c 65 73 2d > 0010: 6c 78 bb 01 00 00 00 00 Read 3 bytes of SSL record < 0000: 01 00 08 Server response to hostname packet is error 0x08 Creating SSL connection failed Please let me know if there's something else I can do to help you troubleshoot. On Wed, 2018-08-29 at 13:57 -0700, Daniel Lenski wrote: > On Wed, Aug 29, 2018 at 12:13 PM, Brandon Liles <brandon.liles at gmail. > com> wrote: > > I've found a few others reporting this problem, but no resolution. > When > connecting to a pulse secure endpoint, authentication is successful > (I > can see the DSID cookie in the http traffic), but when openconnect > tries to establish the VPN connection I get: > > Read 3 bytes of SSL record > < 0000: 01 00 08 > Server response to hostname packet is error 0x08 > Creating SSL connection failed > > I initially tried 7.08 from the Ubuntu 18.04 repositories. When that > didn't work I compiled from source so I have: > openconnect --version > OpenConnect version v7.08-125-g31b5c4a > Using OpenSSL. Features present: TPM (OpenSSL ENGINE not present), > HOTP > software token, TOTP software token, DTLS, ESP > Supported protocols: anyconnect (default), nc, gp > > You get the exact same result with both v7.08 and v7.08-125-g31b5c4a? > (The newer build includes some patches I submitted which makes the > Juniper connection a little more resilient in some cases.) > > There was another very similar report recently: > http://lists.infradead.org/pipermail/openconnect-devel/2018-July/0049 > 54.html > > > I've tried configuring the host checker software and altering my os > param, but always get the same error. > > If you're getting past the authentication and you're getting the DSID > cookie, I don't think the OS or host checker have anything to do with > this result. > > It appears that some Juniper servers don't respond in the same way to > the "vestigial authentication packet" as most of them, but we don't > understand what's different about them. (At least, I don't.) > > In order to figure out what's different about this server, can you > extract the DSID cookie, and run openconnect as follows (highest > logging level), and share as much as possible of the resulting log > output? Obfuscate passwords, and usernames/hostnames/IPs if you want. > > openconnect --dump-http-traffic -vvvv --protocol=nc > --cookie="DSID=...." SERVER > > -Dan >
