XML response has no "auth" node

[Cary Robbins]

So, that seems like it sort of works, but I'm not entirely sure.
There's an Okta workflow to log into the VPN, so I try it from my
browser then steal the cookie, using it on the command line. Note that
I'm using the entire Set-Cookie header, which seems to contain a few
cookies; although, none of them are DSID.

---------------
% sudo openconnect --cookie "<cookie>" --protocol=nc https://vpn.company.com
Connected to xx.xx.xx.xx
SSL negotiation with vpn.company.com
Connected to HTTPS on vpn.company.com
---------------

It stays there for a while. However, I'm not sure how to route network
traffic through this VPN client. Should this happen automatically? I'm
not sure how exactly that would work, but in any case I've tried just
using firefox and navigating to the sites which require VPN. As I
expected, I'm not able to reach them.

Also, at some point the VPN client fails due to some sort of socket read error -

---------------
Failed to read from SSL socket: Error in the pull function.
Error fetching HTTPS response
Creating SSL connection failed
---------------

So I'm skeptical that it's actually ever successful at all. I must
still be doing something wrong. I've also tried to break out each
cookie into separate --cookie arguments, but that seems to yield the
same results.

Best,

Cary

On Thu, Feb 9, 2017 at 2:35 PM, Daniel Lenski <dlenski at gmail.com> wrote:
>> So if I use --juniper I get a "Dumping unknown HTTP form".
>
> What does that unknown form look like?
>
> Handling Juniper auth automatically is notoriously difficult because
> Juniper VPNs allow free-form web pages as part of the authentication
> process. They can use anything from simple HTML forms to JavaScript to
> ActiveX controls (!!!) to do the authentication.
>
>> I guess I'd  need to script it somehow to route through a browser so I can log in that way.
>
> The easiest way to get started with a Juniper VPN+OpenConnect is
> usually to do the login in the web browser, and then "steal" the DSID
> cookie from the resulting Juniper web portal page, after a successful
> login.
>
> Then start openconnect using that cookie, and bypass the
> authentication-form-scraping entirely:
>
>     openconnect --cookie "DSID=deadbeefdeadbeefdeadbeef" --protocol=nc
> junipervpn.company.com
>
> Dan
>
> On Thu, Feb 9, 2017 at 7:05 AM, Cary Robbins <carymrobbins at gmail.com> wrote:
>> So if I use --juniper I get a "Dumping unknown HTTP form". I guess I'd
>> need to script it somehow to route through a browser so I can log in
>> that way.
>>
>> Also, once I get that output I then get "Failed to read from SSL
>> socket: Error in the pull function." for a while. Possibly this is
>> just due to some sort of cache issue.
>>
>> On Sat, Feb 4, 2017 at 8:48 PM, Daniel Lenski <dlenski at gmail.com> wrote:
>>> On Thu, Feb 2, 2017 at 7:05 PM, Cary Robbins <carymrobbins at gmail.com> wrote:
>>>>
>>>> Attempting to connect to a VPN server yields the following error: XML
>>>> response has no "auth" node
>>>>
>>>> From the looks of it, it seems like maybe it's in some sort of redirect loop.
>>>>
>>>> Any clues on how we might be able to resolve this issue?
>>>
>>> Run with --dump-http-traffic to see what XML form is causing
>>> OpenConnect to get confused.