Connecting to Pulse Secure results in SSL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks! Here are the results.

1. I tried the hostname of a machine that is able to connect (which
incidentally has a dash in it also), I tried "localhost", still error
0x08.

2. Yes I get error 0x05 when I set the hostname to "".

3. Yes I get the same result when I remove the client cert after
authenticating and only include the cookie.

David Woodhouse also replied and said this reminds him of a Pulse
endpoint that only allows Proxy Web Access and not an IP Tunnel. I
think he may be correct that this is what error 0x08 indicates. When I
authenticate in a browser, I get a page that is limited to various
proxy web bookmarks and RDP sessions that it tells me are not supported
n my OS (I'm assuming Java only maybe?). However, when I use the Pulse
Secure client software on a supported machine, after authentication, it
runs the hostchecker to verify compliance, checking things like AV and
firewall and then establishes the tunnel. So my guess is, when
openconnect is sending the hostname, the Pulse Secure app is doing some
second level of authentication or requesting the host checker bits or
something.

I'll see if I can get some captures of the official client to get more
information.

Thank you both.


On Wed, 2018-08-29 at 20:56 -0700, Daniel Lenski wrote:
> On Wed, Aug 29, 2018 at 6:46 PM, Brandon Liles <brandon.liles at gmail.c
> om> 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/002
> 820.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/002
> 899.html
> 



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux