On Wed, Aug 29, 2018 at 6:46 PM, Brandon Liles <brandon.liles at gmail.com> wrote:
> 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.
>
Thanks. I noticed the local hostname specified in your auth packet contains
a '-', which I thought might conceivably confuse some buggy server. But
I tried specifying hostnames with '-' on two different Juniper VPNs, and
both accepted it. So that's not it.
More thing to try:
1) You may want to try varying the local hostname (e.g.
`--local-hostname localhost` or
`--local-hostname NAME_OF_A_COMPUTER_THAT_WORKS_WITH_THE_OFFICIAL_CLIENT`)
2) Try removing the local hostname entirely (e.g.
`--local-hostname ""`). Do you get "error 0x05" instead?
> 0000: 0d 00 00 04 00 00 00 00 00 bb 01 00 00 00 00
Read 3 bytes of SSL record
< 0000: 01 00 05
Server response to hostname packet is error 0x05
3) I notice that your connection requires a client certificate. VPN
servers have many quirky and buggy behaviors when client
certificates are involved. Try this: specify the client certificate
for authentication (to get the DSID), but omit it when trying to
actually connect.
In other words, first get the DSID as you've been doing, and then?
# LEAVE OFF THE CLIENT CERT!
openconnect -C 'DSID=...' vpn.company.com
Does that give the same result?
Assuming #1 and #3 don't change anything, and #2 gives you error 0x05
instead, MITM'ing and capturing traffic from a working official client
would probably be the only next step.
Dan
ps- I found another report of the same error 0x08:
http://lists.infradead.org/pipermail/openconnect-devel/2015-March/002820.html
pps- Here's some evidence that Juniper does strange things with client
certificates, although this one is from the authentication part and
*not* from the connection-initiation part:
http://lists.infradead.org/pipermail/openconnect-devel/2015-April/002899.html
