From gareth at garethwilliams.me.uk  Sun Jan  1 06:53:49 2017
From: gareth at garethwilliams.me.uk (Gareth Williams)
Date: Sun, 1 Jan 2017 14:53:49 +0000
Subject: NetworkManager-openconnect with X.509 Certificates
Message-ID: <83bd5cbe-93bf-6f8b-55b7-9ef1f25b62a3@garethwilliams.me.uk>

I'm trying to figure out why I can easily connect to my openconnect
server when using the command line, but cannot connect when using
NetworkManager-openconnect.

The successful command line is simply:

/usr/sbin/openconnect <hostname>:444 --certificate gareth.crt --sslkey
gareth.key --cafile cert1.crt

and I get:

POST https://<hostname>:444/
Attempting to connect to server <IP address>:444
Using client certificate 'gareth'
SSL negotiation with <hostname>
Connected to HTTPS on <hostname>
XML POST enabled
SSL negotiation with <hostname>
Connected to HTTPS on <hostname>
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 90, Keepalive 32400
Connected tun0 as 10.1.2.32, using SSL
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS1.2)-(RSA)-(AES-128-GCM).

after which, routes all look good and traceroute shows my traffic going
via the remote server.

However, if I transpose that to NetworkManager's openconnect GUI and try
to connect, it instantly fails.  I used the --cafile above for 'CA
Certificate', --certificate above for 'User Certificate' and --sslkey
for 'Private Key'.

running:

execsnoop -a16

shows that NetworkManager is running the following when I attempt to
connect:

/usr/sbin/openconnect --servercert
sha1:11e55e29dceaf27a52a039af9844c0b6d2b9abda --syslog --cookie-on-stdin
--script
/usr/lib/NetworkManager/nm-openconnect-service-openconnect-helper
--interface vpn0 <IP address>:444

I noticed that there is no mention of certificates in that command.

I ran that command manually and I get nothing out other than:

Failed to get a WebVPN cookie.

I then removed the --syslog and now I get more:

POST https://<IP address>:444/
Attempting to connect to server <IP address>:444
SSL negotiation with <IP address>
Server certificate verify failed: signer not found
SSL connection failure: Error in the pull function.
Failed to open HTTPS connection to <IP address>
Failed to obtain WebVPN cookie

Adding multiple -v options doesn't show any more information.

Getting hold of a WebVPN Cookie by adding the --authenticate to the
successful manual command line above and passing that using echo to the
above simply removes the 'Failed to obtain WebVPN cookie' message. Still
no connection.

Appending the three X.509 related command line options to the failing NM
one, gives me:

Attempting to connect to server <IP address>:444
Using client certificate 'gareth'
SSL negotiation with <IP address>
Server certificate verify failed: certificate does not match hostname
Connected to HTTPS on <IP address>
Got inappropriate HTTP CONNECT response: HTTP/1.1 401 Unauthorized
Creating SSL connection failed

which is better, but not correct.

Removing the --cookie-on-stdin finally gets me connected:

POST https://<IP address>:444/
Attempting to connect to server <IP address>:444
Using client certificate 'gareth'
SSL negotiation with <IP address>
Server certificate verify failed: certificate does not match hostname
Connected to HTTPS on <IP address>
XML POST enabled
SSL negotiation with <IP address>
Server certificate verify failed: certificate does not match hostname
Connected to HTTPS on <IP address>
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 90, Keepalive 32400

** (process:23870): WARNING **: Could not send configuration
information: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The
name org.freedesktop.NetworkManager.openconnect was not provided by any
.service files
Connected vpn0 as 10.1.2.32, using SSL
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS1.2)-(RSA)-(AES-128-GCM).

Now.  I'm certain that I'm not the only person to ever attempt to
connect to ocserv using NetworkManager-openconnect and X.509
certificates.  That leads me to believe that the software is good and
that I'm missing a trick somewhere.  I've scratched my head for a day or
so trying to figure this out, but I'm stumped by the strange command
executed by NetworkManager and am worried that I've gone down a rabbit
hole with this.

For info, I'm using network-manager-openconnect_1.2.2-1_amd64.deb and
openconnect_7.06-2build3_amd64.deb at the client (on Ubuntu 16.10) and
on the server, ocserv is 0.11.6 running on CentOS-7

Can someone kindly point me back onto the correct track?

Thanks in advance,

Gareth


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3849 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20170101/ee05b3a1/attachment.p7s>

From dlenski at gmail.com  Mon Jan  2 13:29:47 2017
From: dlenski at gmail.com (Daniel Lenski)
Date: Mon, 2 Jan 2017 13:29:47 -0800
Subject: NetworkManager-openconnect with X.509 Certificates
In-Reply-To: <83bd5cbe-93bf-6f8b-55b7-9ef1f25b62a3@garethwilliams.me.uk>
References: <83bd5cbe-93bf-6f8b-55b7-9ef1f25b62a3@garethwilliams.me.uk>
Message-ID: <CAOw_LSHhOa9qWD1pm3tVgSJPF7x9S7x6daek-19mYkj7EQ9ofg@mail.gmail.com>

On Sun, Jan 1, 2017 at 6:53 AM, Gareth Williams
<gareth at garethwilliams.me.uk> wrote:
>
> I'm trying to figure out why I can easily connect to my openconnect
> server when using the command line, but cannot connect when using
> NetworkManager-openconnect.
>
> The successful command line is simply:
>
> /usr/sbin/openconnect <hostname>:444 --certificate gareth.crt --sslkey
> gareth.key --cafile cert1.crt

What you are doing here could be called a "single-pass" connection:
you are telling OpenConnect to connect to the gateway, authenticate,
obtain a session cookie, and then use that cookie to set up the VPN
tunnel? all at once.

> However, if I transpose that to NetworkManager's openconnect GUI and try
> to connect, it instantly fails.  I used the --cafile above for 'CA
> Certificate', --certificate above for 'User Certificate' and --sslkey
> for 'Private Key'.
>
> running:
>
> execsnoop -a16
>
> shows that NetworkManager is running the following when I attempt to
> connect:
>
> /usr/sbin/openconnect --servercert
> sha1:11e55e29dceaf27a52a039af9844c0b6d2b9abda --syslog --cookie-on-stdin
> --script
> /usr/lib/NetworkManager/nm-openconnect-service-openconnect-helper
> --interface vpn0 <IP address>:444
>
> I noticed that there is no mention of certificates in that command.

NetworkManager, by contrast, uses a "two-pass" connection approach.
Per the OC manual, there are two phases of the VPN setup, which can be
run *separately*: http://www.infradead.org/openconnect/manual.html

    The connection happens in two phases. First there is a simple
HTTPS connection over which the user authenticates somehow - by using
a certificate, or password or SecurID, etc.
    Having authenticated, the user is rewarded with an HTTP cookie
which can be used to make the real VPN connection.

    The second phase uses that cookie in an HTTPS CONNECT request, and
data packets can be passed over the resulting connection. In auxiliary
headers exchanged with the
    CONNECT request, a Session-ID and Master Secret for a DTLS
connection are also exchanged, which allows data  transport over UDP
to occur.

As far as I know, recent versions of NM-openconnect use libopenconnect
for the first phase, and run the actual openconnect binary for the
second phase. When you copy the command used by NM-openconnect, you
are only doing the second phase of the connection, which will always
fail because you aren't giving it a valid cookie.

You should try doing a two-pass connection from the CLI:

$ /usr/sbin/openconnect <hostname>:444 --certificate gareth.crt
--sslkey gareth.key --cafile cert1.crt --authenticate
...
Enter your username and password
Username: ?
Password: ?
?
COOKIE=3311180634 at 13561856@1339425499 at B315A0E29D16C6FD92EE
HOST=10.0.0.1:444
FINGERPRINT=sha1:11e55e29dceaf27a52a039af9844c0b6d2b9abda

$ <use the variables shown above>

$ echo $COOKIE | /usr/sbin/openconnect $HOST --cookie-on-stdin
--servercert $FINGERPRINT
?
Connection established.

Notice that the certificate and login credentials are NOT used in the
second pass; only the cookie is used. Does this work? If so, then we
know the two-pass connection works from the command-line, so there
must be something missing in how NM is invoking the second phase.

-Dan


From khankin.konstantin at gmail.com  Fri Jan  6 12:19:38 2017
From: khankin.konstantin at gmail.com (Konstantin M. Khankin)
Date: Fri, 6 Jan 2017 22:19:38 +0200
Subject: Possible bug in ocserv-worker http header parsing
Message-ID: <CAO9MGy5PAT04H7BLBD15Bvs5k-=J2CUCAktvj3SQsfw+zJD8YQ@mail.gmail.com>

HI!

I've just installed and configured ocserv on my centos box:
ocserv-0.11.6-1.el7.x86_64
http-parser-2.7.1-3.el7.x86_64

I'm using openconnect client from ubuntu:
OpenConnect version v5.02
Using GnuTLS. Features present: PKCS#11, TOTP software token, DTLS
(using OpenSSL)

Trying to establish connection:
$ openconnect -vvv <HOST> --cafile=<FILE> --no-xmlpost
GET https://<HOST>/
Attempting to connect to server <ADDRESS>
SSL negotiation with <HOST>
Connected to HTTPS on <HOST>
Failed to read from SSL socket: A TLS packet with unexpected length
was received.
Error fetching HTTPS response
Failed to obtain WebVPN cookie

I checked with wireshark that TLS handhsake happens correctly and ran
ocserv in foreground with debugging. I saw the following:
ocserv[6554]: TLS[<5>]: REC[0x7f98e90d7df0]: Received Packet
Application Data(23) with length: 176
ocserv[6554]: TLS[<5>]: REC[0x7f98e90d7df0]: Decrypted Packet[1]
Application Data(23) with length: 147
ocserv[6554]: worker: <CLIENT IP> HTTP processing: : Host
ocserv[6554]: worker: <CLIENT IP> HTTP processing: : HostUser-Agent
ocserv[6554]: worker: <CLIENT IP> HTTP processing: : HostUser-AgentAccept
ocserv[6554]: worker: <CLIENT IP> HTTP processing: :
HostUser-AgentAcceptAccept-Encoding
ocserv[6554]: worker: <CLIENT IP> HTTP processing: :
HostUser-AgentAcceptAccept-EncodingX-Transcend-Version
ocserv[6550]: main: <CLIENT IP> worker terminated
ocserv[6550]: main: <CLIENT IP> user disconnected (reason:
unspecified, rx: 0, tx: 0)

ocserv-worker dies after it tries to parse http header. Given that
header options are being concatenated in debug output, I'm not sure if
it's just a bug in debug output or options are parsed wrong

Could you please have a look?

Thanks!

-- 
Khankin Konstantin


From n.mavrogiannopoulos at gmail.com  Sat Jan  7 06:46:44 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sat, 7 Jan 2017 15:46:44 +0100
Subject: Possible bug in ocserv-worker http header parsing
In-Reply-To: <CAO9MGy5PAT04H7BLBD15Bvs5k-=J2CUCAktvj3SQsfw+zJD8YQ@mail.gmail.com>
References: <CAO9MGy5PAT04H7BLBD15Bvs5k-=J2CUCAktvj3SQsfw+zJD8YQ@mail.gmail.com>
Message-ID: <CAJU7zaK6Y4=TRb3sTdhAh5ixDsQ2FLGZD7_ae9TZ0hDZw2=O6w@mail.gmail.com>

Please report it against EPEL and http-parser. It may be related to:
https://bugzilla.redhat.com/show_bug.cgi?id=1374081

On Fri, Jan 6, 2017 at 9:19 PM, Konstantin M. Khankin
<khankin.konstantin at gmail.com> wrote:
> HI!
>
> I've just installed and configured ocserv on my centos box:
> ocserv-0.11.6-1.el7.x86_64
> http-parser-2.7.1-3.el7.x86_64
>
> I'm using openconnect client from ubuntu:
> OpenConnect version v5.02
> Using GnuTLS. Features present: PKCS#11, TOTP software token, DTLS
> (using OpenSSL)
>
> Trying to establish connection:
> $ openconnect -vvv <HOST> --cafile=<FILE> --no-xmlpost
> GET https://<HOST>/
> Attempting to connect to server <ADDRESS>
> SSL negotiation with <HOST>
> Connected to HTTPS on <HOST>
> Failed to read from SSL socket: A TLS packet with unexpected length
> was received.
> Error fetching HTTPS response
> Failed to obtain WebVPN cookie
>
> I checked with wireshark that TLS handhsake happens correctly and ran
> ocserv in foreground with debugging. I saw the following:
> ocserv[6554]: TLS[<5>]: REC[0x7f98e90d7df0]: Received Packet
> Application Data(23) with length: 176
> ocserv[6554]: TLS[<5>]: REC[0x7f98e90d7df0]: Decrypted Packet[1]
> Application Data(23) with length: 147
> ocserv[6554]: worker: <CLIENT IP> HTTP processing: : Host
> ocserv[6554]: worker: <CLIENT IP> HTTP processing: : HostUser-Agent
> ocserv[6554]: worker: <CLIENT IP> HTTP processing: : HostUser-AgentAccept
> ocserv[6554]: worker: <CLIENT IP> HTTP processing: :
> HostUser-AgentAcceptAccept-Encoding
> ocserv[6554]: worker: <CLIENT IP> HTTP processing: :
> HostUser-AgentAcceptAccept-EncodingX-Transcend-Version
> ocserv[6550]: main: <CLIENT IP> worker terminated
> ocserv[6550]: main: <CLIENT IP> user disconnected (reason:
> unspecified, rx: 0, tx: 0)
>
> ocserv-worker dies after it tries to parse http header. Given that
> header options are being concatenated in debug output, I'm not sure if
> it's just a bug in debug output or options are parsed wrong
>
> Could you please have a look?
>
> Thanks!
>
> --
> Khankin Konstantin
>
> _______________________________________________
> openconnect-devel mailing list
> openconnect-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/openconnect-devel


From n.mavrogiannopoulos at gmail.com  Sat Jan  7 06:52:29 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sat, 7 Jan 2017 15:52:29 +0100
Subject: Possible bug in ocserv-worker http header parsing
In-Reply-To: <CAO9MGy5PAT04H7BLBD15Bvs5k-=J2CUCAktvj3SQsfw+zJD8YQ@mail.gmail.com>
References: <CAO9MGy5PAT04H7BLBD15Bvs5k-=J2CUCAktvj3SQsfw+zJD8YQ@mail.gmail.com>
Message-ID: <CAJU7zaJ1S=guzyHX3k+fQdpM+dZbhq8fJqOd=az=b6o2XTnSuA@mail.gmail.com>

On Fri, Jan 6, 2017 at 9:19 PM, Konstantin M. Khankin
<khankin.konstantin at gmail.com> wrote:
> HI!
>
> I've just installed and configured ocserv on my centos box:
> ocserv-0.11.6-1.el7.x86_64
> http-parser-2.7.1-3.el7.x86_64

You can verify whether http-parser is the culprit for this issue by using
yum downgrade http-parser


regards,
Nikos


From bjorn.ketelaars at hydroxide.nl  Sat Jan  7 12:29:31 2017
From: bjorn.ketelaars at hydroxide.nl (=?utf-8?B?QmrDtnJu?= Ketelaars)
Date: Sat, 7 Jan 2017 21:29:31 +0100
Subject: ocserv and OCSP
Message-ID: <20170107202931.ohlfmq7pgwzkazcu@gateway.lan>

>From ocserv(8) it is not clear to me if ocserv automatically picks up an
update of the response file as generated by ocsptool.

Checking the OCSP status from ocserv AFTER an response update from ocsptool
suggests that a restart of ocserv is required:

$ ocsptool --ask --load-cert=cert.pem  --load-issuer=chain.pem --outfile ocsp.der
...
                Certificate Status: good
                This Update: Sat Jan 07 04:00:00 UTC 2017
                Next Update: Sat Jan 14 04:00:00 UTC 2017
...

$ nc -cv vpn.domain 443
...
  this update: Tue Jan  3 05:00:00 2017
  next update: Tue Jan 10 05:00:00 2017
  revocation:
...


ocserv(8) also states that the response file needs to be replaced in an atomic
way. If I'm not mistaken this means:
1.) Write output of ocsptool to a temp file;
2.) mv temp file to resonse file (as defined in ocserv.conf: ocsp-response)

Any ideas maybe...or should I just restart ocserv?

-- 
Bj?rn Ketelaars
GPG key: 0x4F0E5F21


From n.mavrogiannopoulos at gmail.com  Sun Jan  8 01:32:30 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sun, 8 Jan 2017 10:32:30 +0100
Subject: ocserv and OCSP
In-Reply-To: <20170107202931.ohlfmq7pgwzkazcu@gateway.lan>
References: <20170107202931.ohlfmq7pgwzkazcu@gateway.lan>
Message-ID: <CAJU7zaL3p9ETjHQy4h8qjiXYc1jT+gSokpP3fbV4Gh7Q0VgXyQ@mail.gmail.com>

On Sat, Jan 7, 2017 at 9:29 PM, Bj?rn Ketelaars
<bjorn.ketelaars at hydroxide.nl> wrote:
> From ocserv(8) it is not clear to me if ocserv automatically picks up an
> update of the response file as generated by ocsptool.

All reloads of files in ocserv (certs and ocsp responses) are done
during the maintenance window of the server, something that happens
periodically, every 15 minutes. So while the reload will not be
imminent it will be done. To force it you can send the HUP signal to
server.

> ocserv(8) also states that the response file needs to be replaced in an atomic
> way. If I'm not mistaken this means:
> 1.) Write output of ocsptool to a temp file;
> 2.) mv temp file to resonse file (as defined in ocserv.conf: ocsp-response)

That's what it means.

regards,
Nikos


From dlenski at gmail.com  Sun Jan  8 12:39:17 2017
From: dlenski at gmail.com (Daniel Lenski)
Date: Sun,  8 Jan 2017 12:39:17 -0800
Subject: [PATCH] add oncp_bye() to logout the Juniper session
Message-ID: <1483907957-10973-1-git-send-email-dlenski@gmail.com>

The nc protocol lacked a .vpn_close_session function; without logout, the
VPN cookie remains active and can be used to restart the session, which is a
security hazard?especially when passing around OpenConnect logs on the
mailing list for development and troubleshooting.

Juniper logout is straightforward: GET /dana-na/auth/logout.cgi (with the
appropriate DSID cookie set).

Signed-off-by: Daniel Lenski <dlenski at gmail.com>
---
 library.c              |  2 +-
 oncp.c                 | 25 +++++++++++++++++++++++++
 openconnect-internal.h |  1 +
 3 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/library.c b/library.c
index 824338e..6fb90ed 100644
--- a/library.c
+++ b/library.c
@@ -122,7 +122,7 @@ const struct vpn_proto openconnect_protos[] = {
 #endif
 	}, {
 		.name = "nc",
-		.vpn_close_session = NULL,
+		.vpn_close_session = oncp_bye,
 		.tcp_connect = oncp_connect,
 		.tcp_mainloop = oncp_mainloop,
 		.add_http_headers = oncp_common_headers,
diff --git a/oncp.c b/oncp.c
index 3c7cfa1..f8f7a25 100644
--- a/oncp.c
+++ b/oncp.c
@@ -1257,3 +1257,28 @@ int oncp_mainloop(struct openconnect_info *vpninfo, int *timeout)
 	/* Work is not done if we just got rid of packets off the queue */
 	return work_done;
 }
+
+int oncp_bye(struct openconnect_info *vpninfo, const char *reason)
+{
+	char *orig_path;
+	char *res_buf=NULL;
+	int ret;
+
+	/* We need to close and reopen the HTTPS connection (to kill
+	 * the oncp tunnel) and submit a new HTTPS request to logout.
+	 */
+	openconnect_close_https(vpninfo, 0);
+
+	orig_path = vpninfo->urlpath;
+	vpninfo->urlpath = strdup("dana-na/auth/logout.cgi"); /* redirect segfaults without strdup */
+	ret = do_https_request(vpninfo, "GET", NULL, NULL, &res_buf, 0);
+	vpninfo->urlpath = orig_path;
+
+	if (ret < 0)
+		vpn_progress(vpninfo, PRG_ERR, _("Logout failed.\n"));
+	else
+		vpn_progress(vpninfo, PRG_INFO, _("Logout successful.\n"));
+
+	free(res_buf);
+	return ret;
+}
diff --git a/openconnect-internal.h b/openconnect-internal.h
index a24a9e4..ead2e43 100644
--- a/openconnect-internal.h
+++ b/openconnect-internal.h
@@ -840,6 +840,7 @@ void oncp_common_headers(struct openconnect_info *vpninfo, struct oc_text_buf *b
 int queue_esp_control(struct openconnect_info *vpninfo, int enable);
 int oncp_connect(struct openconnect_info *vpninfo);
 int oncp_mainloop(struct openconnect_info *vpninfo, int *timeout);
+int oncp_bye(struct openconnect_info *vpninfo, const char *reason);
 
 /* lzs.c */
 int lzs_decompress(unsigned char *dst, int dstlen, const unsigned char *src, int srclen);
-- 
2.7.4



From softman at tfm.ro  Mon Jan  9 03:17:47 2017
From: softman at tfm.ro (Liviu Andreicut)
Date: Mon, 9 Jan 2017 13:17:47 +0200
Subject: tunnel-all-dns=true with Mac OS X & iOS tethering issues
Message-ID: <2A8F25C3-46E7-4C20-9211-009D2CFE28DD@tfm.ro>

Hello, 

I've stumbled upon an issue that was very difficult to isolate, because it happens only if all the above conditions are met:
using Mac OS X (Sierra, but tested also on El Capitan)
single Internet connection through an iOS device setup as hotspot (iOS 10, but tested also on 8 and 9)
ocserv option tunnel-all-dns=true
split routing enabled (route = A.B.C.D/P)
Using this, the result is that the client is only able to reach the prefixes specified as routes in ocserv's config file, with no access to the Internet and no DNS resolving. What actually happens in the client is that the default route is not used, as seen below (note the "I" flag). 
Ping-ing 8.8.8.8 results in:
ping 8.8.8.8 
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host

netstat -nrt Routing tables
Internet: Destination Gateway Flags Refs Use Netif Expire
default 172.20.10.1 UGScI 12 0 en0
Note that 172.20.10.1 is the IP address of the hotspot (the iOS device), and that one responds to ICMP requests and also the internal resources advertised over the tunnel respond properly.

The above issue is overcome by using split-dns on the ocserv configuration and disabling tunnel-all-dns, but that configuration exhibits other issues on Linux.

Does anyone have an idea of this?
--
Liviu Andreicut 



From dlenski at gmail.com  Tue Jan 10 19:02:04 2017
From: dlenski at gmail.com (Daniel Lenski)
Date: Tue, 10 Jan 2017 19:02:04 -0800
Subject: [PATCH v2 0/2] revised patches for
 openconnect_get_supported_protocols() API
In-Reply-To: <20161226235344.29128-1-dlenski@gmail.com>
Message-ID: <cover.1484103570.git.dlenski@gmail.com>

The first creates a public API function, openconnect_get_supported_protocols(). The 
second patch uses this function to show protocol support in the version and usage
messages.

    $ openconnect -V
    OpenConnect version v7.07-248-g367268c-dirty
    Using GnuTLS. Features present: PKCS#11, RSA software token, HOTP software token, TOTP software token, Yubikey OATH, System keys, DTLS, ESP
    Supported protocols: anyconnect (default), nc, gp

    $ openconnect --help
    ...    
    Set VPN protocol:
      --protocol=anyconnect       Cisco AnyConnect or ocserv (default)
      --protocol=nc               Juniper Network Connect (also supported by Junos Pulse servers)
      --protocol=gp               Palo Alto Networks' GlobalProtect

Dan Lenski (1):
  enumerate supported VPN protocols via
    openconnect_get_supported_protocols()

Daniel Lenski (1):
  list supported protocols in --version or --help output, using API
    functions

 libopenconnect.map.in  |  5 +++++
 library.c              | 23 +++++++++++++++++++++++
 main.c                 | 46 ++++++++++++++++++++++++++++++++++++++++++----
 openconnect-internal.h |  1 +
 openconnect.h          | 17 +++++++++++++++++
 5 files changed, 88 insertions(+), 4 deletions(-)

-- 
2.7.4



From dlenski at gmail.com  Tue Jan 10 19:02:05 2017
From: dlenski at gmail.com (Daniel Lenski)
Date: Tue, 10 Jan 2017 19:02:05 -0800
Subject: [PATCH v2 1/2] enumerate supported VPN protocols via
 openconnect_get_supported_protocols()
In-Reply-To: <cover.1484103570.git.dlenski@gmail.com>
References: <cover.1484103570.git.dlenski@gmail.com>
Message-ID: <2d8f8866ce977014c900d00d57a22a40187cce22.1484103570.git.dlenski@gmail.com>

From: Dan Lenski <dlenski at gmail.com>

Add a new public function, openconnect_get_supported_protocols(), which
returns a list of protocols supported by the client.  Each supported
protocol has a short name (as accepted by the --protocol command-line
option), description, and list of flags; currently, the only flags are:

  * OPENCONNECT_PROTO_TCP (TCP transport supported)
  * OPENCONNECT_PROTO_UDP (UDP transport supported)

Signed-off-by: Daniel Lenski <dlenski at gmail.com>
---
 libopenconnect.map.in  |  5 +++++
 library.c              | 23 +++++++++++++++++++++++
 openconnect-internal.h |  1 +
 openconnect.h          | 17 +++++++++++++++++
 4 files changed, 46 insertions(+)

diff --git a/libopenconnect.map.in b/libopenconnect.map.in
index 44eea34..749466c 100644
--- a/libopenconnect.map.in
+++ b/libopenconnect.map.in
@@ -92,6 +92,11 @@ OPENCONNECT_5_4 {
 	openconnect_set_pass_tos;
 } OPENCONNECT_5_3;
 
+OPENCONNECT_5_5 {
+ global:
+	openconnect_get_supported_protocols;
+} OPENCONNECT_5_4;
+
 OPENCONNECT_PRIVATE {
  global: @SYMVER_TIME@ @SYMVER_GETLINE@ @SYMVER_JAVA@ @SYMVER_ASPRINTF@ @SYMVER_VASPRINTF@ @SYMVER_WIN32_STRERROR@
 	openconnect_fopen_utf8;
diff --git a/library.c b/library.c
index 55a0dca..3ac0bf3 100644
--- a/library.c
+++ b/library.c
@@ -109,6 +109,7 @@ err:
 const struct vpn_proto openconnect_protos[] = {
 	{
 		.name = "anyconnect",
+		.description = "Cisco AnyConnect or ocserv",
 		.vpn_close_session = cstp_bye,
 		.tcp_connect = cstp_connect,
 		.tcp_mainloop = cstp_mainloop,
@@ -122,6 +123,7 @@ const struct vpn_proto openconnect_protos[] = {
 #endif
 	}, {
 		.name = "nc",
+		.description = "Juniper Network Connect (also supported by Junos Pulse servers)",
 		.vpn_close_session = NULL,
 		.tcp_connect = oncp_connect,
 		.tcp_mainloop = oncp_mainloop,
@@ -137,6 +139,7 @@ const struct vpn_proto openconnect_protos[] = {
 #endif
 	}, {
 		.name = "gp",
+		.description = "Palo Alto Networks' GlobalProtect",
 		.vpn_close_session = gpst_bye,
 		.tcp_connect = gpst_setup,
 		.tcp_mainloop = gpst_mainloop,
@@ -154,6 +157,26 @@ const struct vpn_proto openconnect_protos[] = {
 	{ /* NULL */ }
 };
 
+int openconnect_get_supported_protocols(struct oc_vpn_proto **protos)
+{
+	struct oc_vpn_proto *pr;
+	const struct vpn_proto *p;
+
+	*protos = pr = calloc(sizeof(openconnect_protos)/sizeof(*openconnect_protos), sizeof(*pr));
+	if (!pr)
+		return -ENOMEM;
+
+	for (p = openconnect_protos; p->name; p++, pr++) {
+		pr->name = p->name;
+		pr->description = p->description;
+		if (p->tcp_mainloop)
+			pr->flags |= OPENCONNECT_PROTO_TCP;
+		if (p->udp_mainloop)
+			pr->flags |= OPENCONNECT_PROTO_UDP;
+	}
+	return 0;
+}
+
 int openconnect_set_protocol(struct openconnect_info *vpninfo, const char *protocol)
 {
 	const struct vpn_proto *p;
diff --git a/openconnect-internal.h b/openconnect-internal.h
index 1ab73c5..466828d 100644
--- a/openconnect-internal.h
+++ b/openconnect-internal.h
@@ -257,6 +257,7 @@ struct http_auth_state {
 
 struct vpn_proto {
 	const char *name;
+	const char *description;
 	int (*vpn_close_session)(struct openconnect_info *vpninfo, const char *reason);
 
 	/* This does the full authentication, calling back as appropriate */
diff --git a/openconnect.h b/openconnect.h
index c621765..c3db27f 100644
--- a/openconnect.h
+++ b/openconnect.h
@@ -36,6 +36,9 @@ extern "C" {
 #define OPENCONNECT_API_VERSION_MINOR 4
 
 /*
+ * API version 5.5:
+ *  - Add openconnect_get_supported_protocols()
+ *
  * API version 5.4:
  *  - Add openconnect_set_pass_tos()
  *
@@ -166,6 +169,19 @@ extern "C" {
 
 /****************************************************************************/
 
+/* Enumeration of supported VPN protocols */
+
+#define OPENCONNECT_PROTO_TCP 1
+#define OPENCONNECT_PROTO_UDP 2
+
+struct oc_vpn_proto {
+	const char *name;
+	const char *description;
+	unsigned int flags;
+};
+
+/****************************************************************************/
+
 /* Authentication form processing */
 
 #define OC_FORM_OPT_TEXT	1
@@ -640,6 +656,7 @@ int openconnect_has_oath_support(void);
 int openconnect_has_yubioath_support(void);
 int openconnect_has_system_key_support(void);
 
+int openconnect_get_supported_protocols(struct oc_vpn_proto **protos);
 int openconnect_set_protocol(struct openconnect_info *vpninfo, const char *protocol);
 
 struct addrinfo;
-- 
2.7.4



From dlenski at gmail.com  Tue Jan 10 19:02:06 2017
From: dlenski at gmail.com (Daniel Lenski)
Date: Tue, 10 Jan 2017 19:02:06 -0800
Subject: [PATCH v2 2/2] list supported protocols in --version or --help output,
 using API functions
In-Reply-To: <cover.1484103570.git.dlenski@gmail.com>
References: <cover.1484103570.git.dlenski@gmail.com>
Message-ID: <5daeb4d89aef5a8de4faf226fb6ab40f105f7934.1484103570.git.dlenski@gmail.com>

Signed-off-by: Daniel Lenski <dlenski at gmail.com>
---
 main.c | 46 ++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 42 insertions(+), 4 deletions(-)

diff --git a/main.c b/main.c
index 71be303..d4b99f3 100644
--- a/main.c
+++ b/main.c
@@ -631,10 +631,45 @@ static void print_build_opts(void)
 	}
 
 #ifdef HAVE_DTLS
-	printf("%sDTLS\n", sep);
-#else
-	printf(_("\nWARNING: No DTLS support in this binary. Performance will be impaired.\n"));
+	printf("%sDTLS", sep);
 #endif
+#ifdef HAVE_ESP
+	printf("%sESP", sep);
+#endif
+	printf("\n");
+
+#if !defined(HAVE_DTLS) || !defined(HAVE_ESP)
+	printf(_("WARNING: This binary lacks DTLS and/or ESP support. Performance will be impaired.\n"));
+#endif
+}
+
+static void print_supported_protocols(void)
+{
+	const char *comma = ", ", *sep = comma + 1;
+	struct oc_vpn_proto *protos, *p;
+
+	if (openconnect_get_supported_protocols(&protos)==0) {
+		printf(_("Supported protocols:"));
+		for (p=protos; p->name; p++) {
+			printf("%s%s%s", sep, p->name, p==protos ? _(" (default)") : "");
+			sep = comma;
+		}
+		printf("\n");
+		free(protos);
+	}
+}
+
+static void print_supported_protocols_usage(void)
+{
+	struct oc_vpn_proto *protos, *p;
+
+	if (openconnect_get_supported_protocols(&protos)==0) {
+		printf(_("\n    Set VPN protocol:\n"));
+		for (p=protos; p->name; p++)
+			printf("      --protocol=%-16s %s%s\n",
+				   p->name, p->description, p==protos ? _(" (default)") : "");
+		free(protos);
+	}
 }
 
 #ifndef _WIN32
@@ -750,7 +785,7 @@ static int gai_override_cb(void *cbdata, const char *node,
 static void usage(void)
 {
 	printf(_("Usage:  openconnect [options] <server>\n"));
-	printf(_("Open client for Cisco AnyConnect VPN, version %s\n\n"), openconnect_version_str);
+	printf(_("Open client for multiple VPN protocols, version %s\n\n"), openconnect_version_str);
 	print_build_opts();
 	printf("      --config=CONFIGFILE         %s\n", _("Read options from config file"));
 #ifndef _WIN32
@@ -832,6 +867,8 @@ static void usage(void)
 	printf("      --resolve=HOST:IP           %s\n", _("Use IP when connecting to HOST"));
 	printf("      --os=STRING                 %s\n", _("OS type (linux,linux-64,win,...) to report"));
 	printf("      --dtls-local-port=PORT      %s\n", _("Set local port for DTLS datagrams"));
+	print_supported_protocols_usage();
+
 	printf("\n");
 
 	helpmessage();
@@ -1334,6 +1371,7 @@ int main(int argc, char **argv)
 		case 'V':
 			printf(_("OpenConnect version %s\n"), openconnect_version_str);
 			print_build_opts();
+			print_supported_protocols();
 			exit(0);
 		case 'x':
 			vpninfo->xmlconfig = keep_config_arg();
-- 
2.7.4



From n.mavrogiannopoulos at gmail.com  Tue Jan 10 23:20:07 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 11 Jan 2017 08:20:07 +0100
Subject: [PATCH v2 0/2] revised patches for
 openconnect_get_supported_protocols() API
In-Reply-To: <cover.1484103570.git.dlenski@gmail.com>
References: <20161226235344.29128-1-dlenski@gmail.com>
 <cover.1484103570.git.dlenski@gmail.com>
Message-ID: <CAJU7zaKwVKGJ_52MqcLSKngM2WogCKAHmHs3Z1YPBGyzhDtXDw@mail.gmail.com>

On Wed, Jan 11, 2017 at 4:02 AM, Daniel Lenski <dlenski at gmail.com> wrote:
> The first creates a public API function, openconnect_get_supported_protocols(). The
> second patch uses this function to show protocol support in the version and usage
> messages.
>
>     $ openconnect -V
>     OpenConnect version v7.07-248-g367268c-dirty
>     Using GnuTLS. Features present: PKCS#11, RSA software token, HOTP software token, TOTP software token, Yubikey OATH, System keys, DTLS, ESP
>     Supported protocols: anyconnect (default), nc, gp
>
>     $ openconnect --help
>     ...
>     Set VPN protocol:
>       --protocol=anyconnect       Cisco AnyConnect or ocserv (default)

I wouldn't call the protocol ocserv, but rather 'openconnect'; this is
how we call it at the published draft:
https://tools.ietf.org/html/draft-mavrogiannopoulos-openconnect-00

regards,
Nikos


From dlenski at gmail.com  Wed Jan 11 11:50:01 2017
From: dlenski at gmail.com (Daniel Lenski)
Date: Wed, 11 Jan 2017 11:50:01 -0800
Subject: [PATCH v3 1/2] enumerate supported VPN protocols via
 openconnect_get_supported_protocols()
In-Reply-To: <2d8f8866ce977014c900d00d57a22a40187cce22.1484103570.git.dlenski@gmail.com>
Message-ID: <1484164201-24634-1-git-send-email-dlenski@gmail.com>

From: Dan Lenski <dlenski at gmail.com>

Add a new public function, openconnect_get_supported_protocols(), which
returns a list of protocols supported by the client.  Each supported
protocol has a short name (as accepted by the --protocol command-line
option), description, and list of flags; currently, the only flags are:

  * OPENCONNECT_PROTO_TCP (TCP transport supported)
  * OPENCONNECT_PROTO_UDP (UDP transport supported)

Description of anyconnect protocol adjusted to match IETF draft
standard for openconnect VPN (https://tools.ietf.org/html/draft-mavrogiannopoulos-openconnect-00).

Signed-off-by: Daniel Lenski <dlenski at gmail.com>
---
 libopenconnect.map.in  |  5 +++++
 library.c              | 23 +++++++++++++++++++++++
 openconnect-internal.h |  1 +
 openconnect.h          | 17 +++++++++++++++++
 4 files changed, 46 insertions(+)

diff --git a/libopenconnect.map.in b/libopenconnect.map.in
index 44eea34..749466c 100644
--- a/libopenconnect.map.in
+++ b/libopenconnect.map.in
@@ -92,6 +92,11 @@ OPENCONNECT_5_4 {
 	openconnect_set_pass_tos;
 } OPENCONNECT_5_3;
 
+OPENCONNECT_5_5 {
+ global:
+	openconnect_get_supported_protocols;
+} OPENCONNECT_5_4;
+
 OPENCONNECT_PRIVATE {
  global: @SYMVER_TIME@ @SYMVER_GETLINE@ @SYMVER_JAVA@ @SYMVER_ASPRINTF@ @SYMVER_VASPRINTF@ @SYMVER_WIN32_STRERROR@
 	openconnect_fopen_utf8;
diff --git a/library.c b/library.c
index 55a0dca..3883177 100644
--- a/library.c
+++ b/library.c
@@ -109,6 +109,7 @@ err:
 const struct vpn_proto openconnect_protos[] = {
 	{
 		.name = "anyconnect",
+		.description = "Cisco AnyConnect or openconnect",
 		.vpn_close_session = cstp_bye,
 		.tcp_connect = cstp_connect,
 		.tcp_mainloop = cstp_mainloop,
@@ -122,6 +123,7 @@ const struct vpn_proto openconnect_protos[] = {
 #endif
 	}, {
 		.name = "nc",
+		.description = "Juniper Network Connect (also supported by Junos Pulse servers)",
 		.vpn_close_session = NULL,
 		.tcp_connect = oncp_connect,
 		.tcp_mainloop = oncp_mainloop,
@@ -137,6 +139,7 @@ const struct vpn_proto openconnect_protos[] = {
 #endif
 	}, {
 		.name = "gp",
+		.description = "Palo Alto Networks GlobalProtect",
 		.vpn_close_session = gpst_bye,
 		.tcp_connect = gpst_setup,
 		.tcp_mainloop = gpst_mainloop,
@@ -154,6 +157,26 @@ const struct vpn_proto openconnect_protos[] = {
 	{ /* NULL */ }
 };
 
+int openconnect_get_supported_protocols(struct oc_vpn_proto **protos)
+{
+	struct oc_vpn_proto *pr;
+	const struct vpn_proto *p;
+
+	*protos = pr = calloc(sizeof(openconnect_protos)/sizeof(*openconnect_protos), sizeof(*pr));
+	if (!pr)
+		return -ENOMEM;
+
+	for (p = openconnect_protos; p->name; p++, pr++) {
+		pr->name = p->name;
+		pr->description = p->description;
+		if (p->tcp_mainloop)
+			pr->flags |= OPENCONNECT_PROTO_TCP;
+		if (p->udp_mainloop)
+			pr->flags |= OPENCONNECT_PROTO_UDP;
+	}
+	return 0;
+}
+
 int openconnect_set_protocol(struct openconnect_info *vpninfo, const char *protocol)
 {
 	const struct vpn_proto *p;
diff --git a/openconnect-internal.h b/openconnect-internal.h
index 1ab73c5..466828d 100644
--- a/openconnect-internal.h
+++ b/openconnect-internal.h
@@ -257,6 +257,7 @@ struct http_auth_state {
 
 struct vpn_proto {
 	const char *name;
+	const char *description;
 	int (*vpn_close_session)(struct openconnect_info *vpninfo, const char *reason);
 
 	/* This does the full authentication, calling back as appropriate */
diff --git a/openconnect.h b/openconnect.h
index c621765..c3db27f 100644
--- a/openconnect.h
+++ b/openconnect.h
@@ -36,6 +36,9 @@ extern "C" {
 #define OPENCONNECT_API_VERSION_MINOR 4
 
 /*
+ * API version 5.5:
+ *  - Add openconnect_get_supported_protocols()
+ *
  * API version 5.4:
  *  - Add openconnect_set_pass_tos()
  *
@@ -166,6 +169,19 @@ extern "C" {
 
 /****************************************************************************/
 
+/* Enumeration of supported VPN protocols */
+
+#define OPENCONNECT_PROTO_TCP 1
+#define OPENCONNECT_PROTO_UDP 2
+
+struct oc_vpn_proto {
+	const char *name;
+	const char *description;
+	unsigned int flags;
+};
+
+/****************************************************************************/
+
 /* Authentication form processing */
 
 #define OC_FORM_OPT_TEXT	1
@@ -640,6 +656,7 @@ int openconnect_has_oath_support(void);
 int openconnect_has_yubioath_support(void);
 int openconnect_has_system_key_support(void);
 
+int openconnect_get_supported_protocols(struct oc_vpn_proto **protos);
 int openconnect_set_protocol(struct openconnect_info *vpninfo, const char *protocol);
 
 struct addrinfo;
-- 
2.7.4



From dlenski at gmail.com  Wed Jan 11 11:52:59 2017
From: dlenski at gmail.com (Daniel Lenski)
Date: Wed, 11 Jan 2017 11:52:59 -0800
Subject: [PATCH v2 0/2] revised patches for
 openconnect_get_supported_protocols() API
In-Reply-To: <CAJU7zaKwVKGJ_52MqcLSKngM2WogCKAHmHs3Z1YPBGyzhDtXDw@mail.gmail.com>
References: <20161226235344.29128-1-dlenski@gmail.com>
 <cover.1484103570.git.dlenski@gmail.com>
 <CAJU7zaKwVKGJ_52MqcLSKngM2WogCKAHmHs3Z1YPBGyzhDtXDw@mail.gmail.com>
Message-ID: <CAOw_LSFgxFF8oo8MaE+YJDsiYp7dxpSCL=YXZ2008pMu9_3utA@mail.gmail.com>

On Tue, Jan 10, 2017 at 11:20 PM, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:
> On Wed, Jan 11, 2017 at 4:02 AM, Daniel Lenski <dlenski at gmail.com> wrote:
>>     $ openconnect --help
>>     ...
>>     Set VPN protocol:
>>       --protocol=anyconnect       Cisco AnyConnect or ocserv (default)
>
> I wouldn't call the protocol ocserv, but rather 'openconnect'; this is
> how we call it at the published draft:
> https://tools.ietf.org/html/draft-mavrogiannopoulos-openconnect-00

Thanks, I sent a revised patch. (And it's really great that this is on
track to become a standard!)


From dlenski at gmail.com  Wed Jan 11 20:01:20 2017
From: dlenski at gmail.com (Daniel Lenski)
Date: Wed, 11 Jan 2017 20:01:20 -0800
Subject: SSL-only Juniper VPN that supports SSL DEFLATE compression?
Message-ID: <CAOw_LSHv-RLT5sMLUZ_XfTVRt++MDegXf5ZC1RB8EXjBkJQfCw@mail.gmail.com>

I am doing battle with a Juniper VPN that only allows SSL connections.
It works with OpenConnect, but it's very slow.

The official Windows client is slightly faster, and reports that it is
using "Transport: SSL" with "Compression: DEFLATE".

It appears that OpenConnect v7.08 doesn't currently support oNCP
compression. I was trying to figure out if this could quickly be
hacked in. I took a look at the config TLV values shown by openconnect
for my VPN:

    # openconnect --prot=nc -C DSID=abc123 vpn.server.com --dump -vvv

    Read 3 bytes of SSL record
    Read 344 bytes of SSL record
    Got KMP message 301 of length 322
    Got KMP message 301 of size 322
    Unknown TLV group 3 attr 1 len 1: 00
    Unknown TLV group 3 attr 1 len 2: 01
    Received SSL compression: DEFLATE
    Received split include route 172.20.134.38/255.255.255.255
    Received split include route 172.19.65.83/255.255.255.255
    Received split include route 172.19.65.84/255.255.255.255
    Received split include route 172.19.65.85/255.255.255.255
    Received split include route 172.19.65.86/255.255.255.255
    Received split include route 172.19.65.87/255.255.255.255
    Received split include route 172.19.65.88/255.255.255.255
    Received split include route 172.19.65.89/255.255.255.255
    Received split include route 172.19.65.90/255.255.255.255
    Received split exclude route x.x.x.x/255.255.255.0
    Received MTU 1400 from server
    Received DNS server x.x.x.1
    Received DNS server x.x.x.2
    Received DNS search domain company.com
    Unknown TLV group 2 attr 3 len 4: 01 00 00 00
    Received internal IP address x.x.x.x
    Received netmask 255.255.255.255
    Received internal gateway address x.x.x.x
    Set up DTLS failed; using SSL instead

One value stands out to me:

    Unknown TLV group 3 attr 2 len 1: 01

In the other logs I've found (e.g.
http://lists.infradead.org/pipermail/openconnect-devel/2015-April/002878.html)
this field has a value of 0.

Does anyone else use a Juniper VPN that supports *SSL* DEFLATE
compression? Does it return the same config value? Any hint that I'm
on the right track would be appreciated.

I haven't yet figured out any way to induce the server to respond with
DEFLATE-compressed packets.

Thanks,
Dan


From dwmw2 at infradead.org  Fri Jan 13 06:11:13 2017
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 13 Jan 2017 15:11:13 +0100
Subject: [PATCH v3 1/2] enumerate supported VPN protocols via
 openconnect_get_supported_protocols()
In-Reply-To: <1484164201-24634-1-git-send-email-dlenski@gmail.com>
References: <1484164201-24634-1-git-send-email-dlenski@gmail.com>
Message-ID: <1484316673.3817.64.camel@infradead.org>

On Wed, 2017-01-11 at 11:50 -0800, Daniel Lenski wrote:
> 
> Add a new public function, openconnect_get_supported_protocols(),
> which
> returns a list of protocols supported by the client.? Each supported
> protocol has a short name (as accepted by the --protocol command-line
> option), description, and list of flags; currently, the only flags
> are:
> 
> ? * OPENCONNECT_PROTO_TCP (TCP transport supported)
> ? * OPENCONNECT_PROTO_UDP (UDP transport supported)

Hm, does the caller really care about those? What might make more sense
is a set of flags indicating which authentication features are
meaningful for each protocol ? can it support certificate auth, can it
support OTP, can it support CSD, etc.

Tools like the NetworkManager configuration UI would then disable
certain options depending on the protocol that's selected.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20170113/e56da6ea/attachment.bin>

From dwmw2 at infradead.org  Fri Jan 13 06:15:34 2017
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 13 Jan 2017 15:15:34 +0100
Subject: SSL-only Juniper VPN that supports SSL DEFLATE compression?
In-Reply-To: <CAOw_LSHv-RLT5sMLUZ_XfTVRt++MDegXf5ZC1RB8EXjBkJQfCw@mail.gmail.com>
References: <CAOw_LSHv-RLT5sMLUZ_XfTVRt++MDegXf5ZC1RB8EXjBkJQfCw@mail.gmail.com>
Message-ID: <1484316934.3817.68.camel@infradead.org>

On Wed, 2017-01-11 at 20:01 -0800, Daniel Lenski wrote:
> 
> Does anyone else use a Juniper VPN that supports *SSL* DEFLATE
> compression? Does it return the same config value? Any hint that I'm
> on the right track would be appreciated.

If it really means SSL deflate, then that's negotiated as part of the
SSL handshake. Can you capture and show the SSL session establishment?

Try adding COMP-ALL to the GnuTLS priority string for OpenConnect...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20170113/61155fb0/attachment.bin>

From bj.cardon at gmail.com  Fri Jan 13 11:24:05 2017
From: bj.cardon at gmail.com (Benjamin Cardon)
Date: Fri, 13 Jan 2017 12:24:05 -0700
Subject: Can't connect to Juniper VPN because: "Unknown form ID
 'frmSelectRoles'"
In-Reply-To: <1472328548.4611.25.camel@infradead.org>
References: <CAEjMM-ExbodthyrngWqu1pQjsyuMvxE+Ljhyw376OV-cSBCzhw@mail.gmail.com>
 <CAEjMM-F4iCm5zqKnapwJARW4Z_Wv_T+fUtvDQ=i3tdz8o57w3w@mail.gmail.com>
 <1468974509.32389.0.camel@infradead.org> <2746985.ydzPciMTd7@shtub-cm>
 <CAEjMM-E-hYLtnSyCPiU6wp4iz2VCKXjpfcfk=3THXynk-jn51g@mail.gmail.com>
 <1472153015.61594.616.camel@infradead.org>
 <CAEjMM-EWQk38MkMSzb+LeMqUMcUBnrfz+OXb3skpd19Lx+qpbA@mail.gmail.com>
 <1472197515.61594.619.camel@infradead.org>
 <CA+YjamcgrB6KbYOynMjuRY6qjOG=t9tdthUqevDkWo_pS5rcZA@mail.gmail.com>
 <CAEjMM-EK0OrSDu8EaeES8M4h00Hk5zHzBTRXrhCJ4Zpqk0k_DA@mail.gmail.com>
 <CAEjMM-HTnG30jrHqr0M6UNmq0RG=oniSro8YcFTa=ejuJ_TCAw@mail.gmail.com>
 <1472326980.4611.24.camel@infradead.org>
 <1472328548.4611.25.camel@infradead.org>
Message-ID: <CAEjMM-E_Gxe1kVWt2Q7f+NVgV2ZO_VYteiYXTyn_THn_nM56WQ@mail.gmail.com>

Sorry I accidentally sent this just to David...

I know this thread is quite old, but I had a request.

Can we add a command line param for the role_id/name so that we can
completely automate the login even with this required form? I've
noticed that was done for several other fields and it would be
extremely helpful for my use case.

BJ Cardon

On Sat, Aug 27, 2016 at 2:09 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Sat, 2016-08-27 at 20:43 +0100, David Woodhouse wrote:
>> On Fri, 2016-08-26 at 11:52 -0600, Benjamin Cardon wrote:
>> > Alright so I manually merged in your original cleaned up patch after
>> > reverting the committed changes and it worked swimmingly, so you
>> > definitely lost something in the conversion. Also, is there any way
>> > you can number the options for the available roles?
>>
>> Can you do me a favour and mail me the patch you have against current
>> master, that works? Basically it should just be reverting my
>> cleanups, yes?
>
> No matter, I think I've fixed it. Sorry.
>
> --
> dwmw2
>
>


From dlenski at gmail.com  Sat Jan 14 00:11:59 2017
From: dlenski at gmail.com (Daniel Lenski)
Date: Sat, 14 Jan 2017 00:11:59 -0800
Subject: SSL-only Juniper VPN that supports SSL DEFLATE compression?
In-Reply-To: <1484316934.3817.68.camel@infradead.org>
References: <CAOw_LSHv-RLT5sMLUZ_XfTVRt++MDegXf5ZC1RB8EXjBkJQfCw@mail.gmail.com>
 <1484316934.3817.68.camel@infradead.org>
Message-ID: <CAOw_LSGv5TzLvO8Qnhd_nHuMQk=DqmL0AZ=Hj3k=Nh8D9yw0AA@mail.gmail.com>

On Jan 13, 2017 6:16 AM, "David Woodhouse" <dwmw2 at infradead.org> wrote:
>
> On Wed, 2017-01-11 at 20:01 -0800, Daniel Lenski wrote:
> >
> > Does anyone else use a Juniper VPN that supports *SSL* DEFLATE
> > compression? Does it return the same config value? Any hint that I'm
> > on the right track would be appreciated.
>
> If it really means SSL deflate, then that's negotiated as part of the
> SSL handshake. Can you capture and show the SSL session establishment?
>
> Try adding COMP-ALL to the GnuTLS priority string for OpenConnect...
>

Hmm, that's an interesting idea. I thought I was looking for
compression at the level of the (inner) IP packets exchanged over the
oNCP tunnel, not at the (outer) TLS transport.

Adding +COMP-ALL doesn't seem to do anything, however, as confirmed by
gnutls-cli. This connects without compression:

    $ gnutls-cli -V --priority "NORMAL:+COMP-ALL" vpn.server.com

Taking the observed TLS connection settings and forcing +COMP-DEFLATE
simply results in a failed handshake:

    $ gnutls-cli -V --priority
"NONE:+VERS-TLS1.2:+RSA:+AES-128-CBC:+SHA256:+COMP-DEFLATE"
b2b-portal.renesas.com

It appears that whatever the DEFLATE compression is, it isn't standard
transport level compression. Which is in keeping with what I've
learned from oncp.c ?

                /*
                 * This protocol is horrid. There are encapsulations within
                 * encapsulations within encapsulations. Some of them entirely
                 * gratuitous.


-Dan


From dlenski at gmail.com  Sat Jan 14 00:14:59 2017
From: dlenski at gmail.com (Daniel Lenski)
Date: Sat, 14 Jan 2017 00:14:59 -0800
Subject: [PATCH v3 1/2] enumerate supported VPN protocols via
 openconnect_get_supported_protocols()
In-Reply-To: <1484316673.3817.64.camel@infradead.org>
References: <1484164201-24634-1-git-send-email-dlenski@gmail.com>
 <1484316673.3817.64.camel@infradead.org>
Message-ID: <CAOw_LSE7RwgYrdPTvWGNUoaZFZmN=2EWnij4z4eb79aFi1u2+g@mail.gmail.com>

On Fri, Jan 13, 2017 at 6:11 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Wed, 2017-01-11 at 11:50 -0800, Daniel Lenski wrote:
>>
>> Add a new public function, openconnect_get_supported_protocols(),
>> which
>> returns a list of protocols supported by the client.  Each supported
>> protocol has a short name (as accepted by the --protocol command-line
>> option), description, and list of flags; currently, the only flags
>> are:
>>
>>   * OPENCONNECT_PROTO_TCP (TCP transport supported)
>>   * OPENCONNECT_PROTO_UDP (UDP transport supported)
>
> Hm, does the caller really care about those?

Perhaps not. I mostly added these for demonstration purposes. I was
thinking the client might care about HTTPS-based support, since this
would allow the VPN to work over a proxy, but I don't see any good
reason for a front end to care about UDP.

> What might make more sense
> is a set of flags indicating which authentication features are
> meaningful for each protocol ? can it support certificate auth, can it
> support OTP, can it support CSD, etc.

I will add these. Is it possible for an HTTPS-based protocol *not* to
support client certificates, though?

Thanks,
Dan


From thomaslewis at 0xaa55.me  Sun Jan 15 04:31:07 2017
From: thomaslewis at 0xaa55.me (=?UTF-8?B?VGhvbWFzIExld2lz?=)
Date: Sun, 15 Jan 2017 20:31:07 +0800 (Asia/Hong_Kong)
Subject: =?UTF-8?B?W0JVR10gT2NzZXJ2IElzIEluY29tcGF0aWJsZSB3?=
 =?UTF-8?B?aXRoIHRoZSBMYXRlc3QgaHR0cC1wYXJzZXIgKDIu?=
 =?UTF-8?B?Ny4xKQ==?=
Message-ID: <mailman.0.1484483488.26981.openconnect-devel@lists.infradead.org>

After using yum update to keep all my software up-to-date, I found the ocserv cannot be connected. The TLS connection can be successfully established but it return nothing. I've checked the history of my updating and only http-parser was been upgraded to 2.7.1 which made this problem occur.

So I decided to use an older version like 2.0 and the problem was solved.

My OS: CentOS 7.3.1611


=====================================
Mail?from?Thomas?Lewis?(???)
Tel:?(+86)?13126413113
E-mail:?thomaslewis at 0xAA55.me
E-mail?(Encrypted):?thomaslewis at secure.0xAA55.me
=====================================


From dlenski at gmail.com  Sun Jan 15 13:40:15 2017
From: dlenski at gmail.com (Daniel Lenski)
Date: Sun, 15 Jan 2017 13:40:15 -0800
Subject: [PATCH v3 1/2] enumerate supported VPN protocols via
 openconnect_get_supported_protocols()
In-Reply-To: <1484316673.3817.64.camel@infradead.org>
References: <1484316673.3817.64.camel@infradead.org>
Message-ID: <1484516415-4690-1-git-send-email-dlenski@gmail.com>

Add a new public function, openconnect_get_supported_protocols(), which
returns a list of protocols supported by the client.  Each supported
protocol has a short name (as accepted by the --protocol command-line
option), description, and list of flags.

The flags indicate features that are meaningful for this protocol, to be
used by tools like the Networkmanager configuration UI. Current flags:

  * OC_PROTO_PROXY: can connect via HTTP or SOCKS proxy
  * OC_PROTO_CSD: supports verification of the client via CSD trojan
  * OC_PROTO_AUTH_CERT: supports authentication by client certificate
  * OC_PROTO_AUTH_OTP: supports authentication by OATH HOTP/TOTP token
  * OC_PROTO_AUTH_STOKEN: supports authentication by RSA SecurID token (stoken)

Description of anyconnect protocol adjusted to match IETF draft
standard for openconnect VPN (https://tools.ietf.org/html/draft-mavrogiannopoulos-openconnect-00).

Signed-off-by: Daniel Lenski <dlenski at gmail.com>
---
 libopenconnect.map.in  |  5 +++++
 library.c              | 23 +++++++++++++++++++++++
 openconnect-internal.h |  2 ++
 openconnect.h          | 20 ++++++++++++++++++++
 4 files changed, 50 insertions(+)

diff --git a/libopenconnect.map.in b/libopenconnect.map.in
index 44eea34..749466c 100644
--- a/libopenconnect.map.in
+++ b/libopenconnect.map.in
@@ -92,6 +92,11 @@ OPENCONNECT_5_4 {
 	openconnect_set_pass_tos;
 } OPENCONNECT_5_3;
 
+OPENCONNECT_5_5 {
+ global:
+	openconnect_get_supported_protocols;
+} OPENCONNECT_5_4;
+
 OPENCONNECT_PRIVATE {
  global: @SYMVER_TIME@ @SYMVER_GETLINE@ @SYMVER_JAVA@ @SYMVER_ASPRINTF@ @SYMVER_VASPRINTF@ @SYMVER_WIN32_STRERROR@
 	openconnect_fopen_utf8;
diff --git a/library.c b/library.c
index 55a0dca..becf8c8 100644
--- a/library.c
+++ b/library.c
@@ -109,6 +109,8 @@ err:
 const struct vpn_proto openconnect_protos[] = {
 	{
 		.name = "anyconnect",
+		.description = "Cisco AnyConnect or openconnect",
+		.flags = OC_PROTO_PROXY | OC_PROTO_CSD | OC_PROTO_AUTH_CERT | OC_PROTO_AUTH_OTP | OC_PROTO_AUTH_STOKEN,
 		.vpn_close_session = cstp_bye,
 		.tcp_connect = cstp_connect,
 		.tcp_mainloop = cstp_mainloop,
@@ -122,6 +124,8 @@ const struct vpn_proto openconnect_protos[] = {
 #endif
 	}, {
 		.name = "nc",
+		.description = "Juniper Network Connect (also supported by Junos Pulse servers)",
+		.flags = OC_PROTO_PROXY | OC_PROTO_CSD | OC_PROTO_AUTH_CERT | OC_PROTO_AUTH_OTP,
 		.vpn_close_session = NULL,
 		.tcp_connect = oncp_connect,
 		.tcp_mainloop = oncp_mainloop,
@@ -154,6 +160,23 @@ const struct vpn_proto openconnect_protos[] = {
 	{ /* NULL */ }
 };
 
+int openconnect_get_supported_protocols(struct oc_vpn_proto **protos)
+{
+	struct oc_vpn_proto *pr;
+	const struct vpn_proto *p;
+
+	*protos = pr = calloc(sizeof(openconnect_protos)/sizeof(*openconnect_protos), sizeof(*pr));
+	if (!pr)
+		return -ENOMEM;
+
+	for (p = openconnect_protos; p->name; p++, pr++) {
+		pr->name = p->name;
+		pr->description = p->description;
+		pr->flags = p->flags;
+	}
+	return 0;
+}
+
 int openconnect_set_protocol(struct openconnect_info *vpninfo, const char *protocol)
 {
 	const struct vpn_proto *p;
diff --git a/openconnect-internal.h b/openconnect-internal.h
index 1ab73c5..a7a4740 100644
--- a/openconnect-internal.h
+++ b/openconnect-internal.h
@@ -257,6 +257,8 @@ struct http_auth_state {
 
 struct vpn_proto {
 	const char *name;
+	const char *description;
+	unsigned int flags;
 	int (*vpn_close_session)(struct openconnect_info *vpninfo, const char *reason);
 
 	/* This does the full authentication, calling back as appropriate */
diff --git a/openconnect.h b/openconnect.h
index c621765..5e42cd8 100644
--- a/openconnect.h
+++ b/openconnect.h
@@ -36,6 +36,9 @@ extern "C" {
 #define OPENCONNECT_API_VERSION_MINOR 4
 
 /*
+ * API version 5.5:
+ *  - Add openconnect_get_supported_protocols()
+ *
  * API version 5.4:
  *  - Add openconnect_set_pass_tos()
  *
@@ -166,6 +169,22 @@ extern "C" {
 
 /****************************************************************************/
 
+/* Enumeration of supported VPN protocols */
+
+#define OC_PROTO_PROXY	(1<<0)
+#define OC_PROTO_CSD	(1<<1)
+#define OC_PROTO_AUTH_CERT	(1<<2)
+#define OC_PROTO_AUTH_OTP	(1<<4)
+#define OC_PROTO_AUTH_STOKEN	(1<<8)
+
+struct oc_vpn_proto {
+	const char *name;
+	const char *description;
+	unsigned int flags;
+};
+
+/****************************************************************************/
+
 /* Authentication form processing */
 
 #define OC_FORM_OPT_TEXT	1
@@ -640,6 +659,7 @@ int openconnect_has_oath_support(void);
 int openconnect_has_yubioath_support(void);
 int openconnect_has_system_key_support(void);
 
+int openconnect_get_supported_protocols(struct oc_vpn_proto **protos);
 int openconnect_set_protocol(struct openconnect_info *vpninfo, const char *protocol);
 
 struct addrinfo;
-- 
2.7.4



From n.mavrogiannopoulos at gmail.com  Sun Jan 15 23:23:38 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 16 Jan 2017 08:23:38 +0100
Subject: [BUG] Ocserv Is Incompatible with the Latest http-parser (2.7.1)
In-Reply-To: <E1cSjy6-0002Pi-Cd@bombadil.infradead.org>
References: <E1cSjy6-0002Pi-Cd@bombadil.infradead.org>
Message-ID: <CAJU7zaK8r_jhMPncsAAVG3QBaxiJNYNCWorM0HwZZyGRSeR+YQ@mail.gmail.com>

On Sun, Jan 15, 2017 at 1:31 PM, Thomas Lewis <thomaslewis at 0xaa55.me> wrote:
> After using yum update to keep all my software up-to-date, I found the ocserv cannot be connected. The TLS connection can be successfully established but it return nothing. I've checked the history of my updating and only http-parser was been upgraded to 2.7.1 which made this problem occur.
> So I decided to use an older version like 2.0 and the problem was solved.

That's the correct fix. An other is to use the ocserv rpms from epel testing:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-63c298b073

regards,
Nikos


From syouwa at gmail.com  Tue Jan 17 06:48:05 2017
From: syouwa at gmail.com (syouwa)
Date: Tue, 17 Jan 2017 22:48:05 +0800
Subject: ocserv trying to assign IP address 255.255.255.254 to tun device
 causes authentication failed
Message-ID: <24dbe0b1-766e-04eb-fe8d-100faa60ad79@gmail.com>

Freeradius is my authentication method, I found that ocserv trying to 
assign IP address 255.255.255.254 to tun device and seems that caused 
authentication fail, 255.255.255.254 is the value of Framed-IP-Address 
attribute defined in radgoupreply table, is this a bug?

...
ocserv[6517]: radius-auth: opening session 
QEZrDavGuU+alu9EEOX7WGVCXl/kRtD0iD9rZAPEGY8=
ocserv[6517]: sec-mod: initiating session for user 'syouwa at gmail.com' 
(session: QEZrDa)
ocserv[6516]: main[syouwa at gmail.com]: 111.202.52.130:50127 new user session
ocserv[6516]: main[syouwa at gmail.com]: 111.202.52.130:50127 assigned 
IPv4: 255.255.255.254
ocserv[6516]: main[syouwa at gmail.com]: 111.202.52.130:50127 assigning tun 
device vpns0
ocserv[6516]: main: tun.c:386: vpns0: Error setting DST IPv4: Invalid 
argument
ocserv[6516]: main[syouwa at gmail.com]: 111.202.52.130:50127 failed 
authentication attempt for user 'syouwa at gmail.com'
...


 From rfc2865 Framed-IP-Address definition

...
    Address

       The Address field is four octets.  The value 0xFFFFFFFF indicates
       that the NAS Should allow the user to select an address (e.g.
       Negotiated).  The value 0xFFFFFFFE indicates that the NAS should
       select an address for the user (e.g. Assigned from a pool of
       addresses kept by the NAS).  Other valid values indicate that the
       NAS should use that value as the user's IP address.
...


Thanks,
David


From n.mavrogiannopoulos at gmail.com  Tue Jan 17 07:47:10 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 17 Jan 2017 16:47:10 +0100
Subject: ocserv trying to assign IP address 255.255.255.254 to tun device
 causes authentication failed
In-Reply-To: <24dbe0b1-766e-04eb-fe8d-100faa60ad79@gmail.com>
References: <24dbe0b1-766e-04eb-fe8d-100faa60ad79@gmail.com>
Message-ID: <CAJU7zaLEZ6frvLUe-vQt9yGLpnnmXBhGL9F7L_r13QdY-ZF=aw@mail.gmail.com>

On Tue, Jan 17, 2017 at 3:48 PM, syouwa <syouwa at gmail.com> wrote:
> Freeradius is my authentication method, I found that ocserv trying to assign
> IP address 255.255.255.254 to tun device and seems that caused
> authentication fail, 255.255.255.254 is the value of Framed-IP-Address
> attribute defined in radgoupreply table, is this a bug?
>
> ...
> ocserv[6517]: radius-auth: opening session
> QEZrDavGuU+alu9EEOX7WGVCXl/kRtD0iD9rZAPEGY8=
> ocserv[6517]: sec-mod: initiating session for user 'syouwa at gmail.com'
> (session: QEZrDa)
> ocserv[6516]: main[syouwa at gmail.com]: 111.202.52.130:50127 new user session
> ocserv[6516]: main[syouwa at gmail.com]: 111.202.52.130:50127 assigned IPv4:
> 255.255.255.254
> ocserv[6516]: main[syouwa at gmail.com]: 111.202.52.130:50127 assigning tun
> device vpns0
> ocserv[6516]: main: tun.c:386: vpns0: Error setting DST IPv4: Invalid
> argument
> ocserv[6516]: main[syouwa at gmail.com]: 111.202.52.130:50127 failed
> authentication attempt for user 'syouwa at gmail.com'

Looks easy to fix. Can you try the patch at:
https://gitlab.com/ocserv/ocserv/merge_requests/35

Alternatively, you can configure the server not to send the Frame-IP-Address.

regards,
Nikos


From syouwa at gmail.com  Tue Jan 17 08:42:33 2017
From: syouwa at gmail.com (syouwa)
Date: Wed, 18 Jan 2017 00:42:33 +0800
Subject: ocserv trying to assign IP address 255.255.255.254 to tun device
 causes authentication failed
In-Reply-To: <CAJU7zaLEZ6frvLUe-vQt9yGLpnnmXBhGL9F7L_r13QdY-ZF=aw@mail.gmail.com>
References: <24dbe0b1-766e-04eb-fe8d-100faa60ad79@gmail.com>
 <CAJU7zaLEZ6frvLUe-vQt9yGLpnnmXBhGL9F7L_r13QdY-ZF=aw@mail.gmail.com>
Message-ID: <0456f74d-02ab-6a39-b2ad-32e5584d6847@gmail.com>

Thanks Nikos, After removed Framed-IP-Address from radgourpreply it 
worked fine.

But the patch seems doesn't work, even after I changed "if (ipv4 != 
0xffffffff && ipv4 != 0xfffffffe) "  to  "if (ipv4 != 0xffffffff || ipv4 
!= 0xfffffffe) "

...

ocserv[6470]: sec-mod: initiating session for user 'syouwa at gmail.com' 
(session: hh1Ksv)
ocserv[6469]: main[syouwa at gmail.com]: 111.202.52.130:50618 new user session
ocserv[6469]: main[syouwa at gmail.com]: 111.202.52.130:50618 assigned 
IPv4: 255.255.255.254
ocserv[6469]: main[syouwa at gmail.com]: 111.202.52.130:50618 assigning tun 
device vpns0
ocserv[6469]: main: tun.c:386: vpns0: Error setting DST IPv4: Invalid 
argument
ocserv[6469]: main[syouwa at gmail.com]: 111.202.52.130:50618 failed 
authentication attempt for user 'syouwa at gmail.com'

...


Regards,
David

On 2017/1/17 23:47, Nikos Mavrogiannopoulos wrote:
> On Tue, Jan 17, 2017 at 3:48 PM, syouwa <syouwa at gmail.com> wrote:
>> Freeradius is my authentication method, I found that ocserv trying to assign
>> IP address 255.255.255.254 to tun device and seems that caused
>> authentication fail, 255.255.255.254 is the value of Framed-IP-Address
>> attribute defined in radgoupreply table, is this a bug?
>>
>> ...
>> ocserv[6517]: radius-auth: opening session
>> QEZrDavGuU+alu9EEOX7WGVCXl/kRtD0iD9rZAPEGY8=
>> ocserv[6517]: sec-mod: initiating session for user 'syouwa at gmail.com'
>> (session: QEZrDa)
>> ocserv[6516]: main[syouwa at gmail.com]: 111.202.52.130:50127 new user session
>> ocserv[6516]: main[syouwa at gmail.com]: 111.202.52.130:50127 assigned IPv4:
>> 255.255.255.254
>> ocserv[6516]: main[syouwa at gmail.com]: 111.202.52.130:50127 assigning tun
>> device vpns0
>> ocserv[6516]: main: tun.c:386: vpns0: Error setting DST IPv4: Invalid
>> argument
>> ocserv[6516]: main[syouwa at gmail.com]: 111.202.52.130:50127 failed
>> authentication attempt for user 'syouwa at gmail.com'
> Looks easy to fix. Can you try the patch at:
> https://gitlab.com/ocserv/ocserv/merge_requests/35
>
> Alternatively, you can configure the server not to send the Frame-IP-Address.
>
> regards,
> Nikos



From n.mavrogiannopoulos at gmail.com  Wed Jan 18 06:27:51 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 18 Jan 2017 15:27:51 +0100
Subject: ocserv trying to assign IP address 255.255.255.254 to tun device
 causes authentication failed
In-Reply-To: <0456f74d-02ab-6a39-b2ad-32e5584d6847@gmail.com>
References: <24dbe0b1-766e-04eb-fe8d-100faa60ad79@gmail.com>
 <CAJU7zaLEZ6frvLUe-vQt9yGLpnnmXBhGL9F7L_r13QdY-ZF=aw@mail.gmail.com>
 <0456f74d-02ab-6a39-b2ad-32e5584d6847@gmail.com>
Message-ID: <CAJU7zaKd__4mPDAd9Xr7ZSFNExbjzWDXhYhkoOHxf1LX1_14xg@mail.gmail.com>

On Tue, Jan 17, 2017 at 5:42 PM, syouwa <syouwa at gmail.com> wrote:
> Thanks Nikos, After removed Framed-IP-Address from radgourpreply it worked
> fine.
>
> But the patch seems doesn't work, even after I changed "if (ipv4 !=
> 0xffffffff && ipv4 != 0xfffffffe) "  to  "if (ipv4 != 0xffffffff || ipv4 !=
> 0xfffffffe) "

Thanks. I've updated the patch and added a test case to check the
expected behavior.

regards,
Nikos


From gbcbooksmj at gmail.com  Sat Jan 21 05:52:45 2017
From: gbcbooksmj at gmail.com (Goodman Leung)
Date: Sat, 21 Jan 2017 21:52:45 +0800
Subject: openconnect/ocserv ipv6 setting
Message-ID: <38af525b-506e-4472-e481-7caa7bb02989@gmail.com>

Hi list

does any one have ipv6 work on ocserv ?

i add configure "ipv6-network = 2001:470:c19d:xxxx:xxxx::/64"

and from the debug log output

   assigned IPv6: 2001:470:f91d:c15c:0:74:f141:e500

ipv6 address had been assigned, from when i check my client side , it
did not found ipv6 address on the tun interface

any one can help me with this ?
-- 
best regards
Goodman Leung

sent by thundebird in GMail
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gbcbooksmj.vcf
Type: text/x-vcard
Size: 4 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20170121/93115787/attachment.vcf>

From cernekee at gmail.com  Sat Jan 21 07:45:58 2017
From: cernekee at gmail.com (Kevin Cernekee)
Date: Sat, 21 Jan 2017 07:45:58 -0800
Subject: openconnect/ocserv ipv6 setting
In-Reply-To: <38af525b-506e-4472-e481-7caa7bb02989@gmail.com>
References: <38af525b-506e-4472-e481-7caa7bb02989@gmail.com>
Message-ID: <CAJiQ=7D8fsjKEFp=ED37bES6O5tarRr+Z-CKucrZ0VApvTaGCA@mail.gmail.com>

On Sat, Jan 21, 2017 at 5:52 AM, Goodman Leung <gbcbooksmj at gmail.com> wrote:
> does any one have ipv6 work on ocserv ?
>
> i add configure "ipv6-network = 2001:470:c19d:xxxx:xxxx::/64"
>
> and from the debug log output
>
>   assigned IPv6: 2001:470:f91d:c15c:0:74:f141:e500
>
> ipv6 address had been assigned, from when i check my client side , it
> did not found ipv6 address on the tun interface

It's working for me, using explicit-ipv6 to provide a /128 to specific clients.

You might want to run the client with --dump-http-traffic and look for
these headers:

X-CSTP-Address-Type: IPv6,IPv4
X-CSTP-Address-IP6: 2001:470:f91d:c15c:0:74:f141:e500/128

If your ipv6-network (i.e. the delegation you received from your ISP)
is only a /64, you can try ipv6-subnet-prefix = 128.  Ideally you'd
want to get a /48 or /56 from your ISP, and then hand out a /64 to
each VPN client.


From gbcbooksmj at gmail.com  Sun Jan 22 01:30:52 2017
From: gbcbooksmj at gmail.com (Michael Leung)
Date: Sun, 22 Jan 2017 17:30:52 +0800
Subject: openconnect/ocserv ipv6 setting
In-Reply-To: <CAJ6sgmhmJRvDd93FYia+q4QnmR2QgH2_sf1sgwzC-+V3Ksjdrw@mail.gmail.com>
References: <38af525b-506e-4472-e481-7caa7bb02989@gmail.com>
 <CAJiQ=7D8fsjKEFp=ED37bES6O5tarRr+Z-CKucrZ0VApvTaGCA@mail.gmail.com>
 <CAJ6sgmhmJRvDd93FYia+q4QnmR2QgH2_sf1sgwzC-+V3Ksjdrw@mail.gmail.com>
Message-ID: <CAJ6sgmhA6WjR16bWufOiVSKg3_618pwVhc6fwZNPSOQ4mBk89w@mail.gmail.com>

seems ocserve will automatic correct the mtu value,   any one how to stop it ?

On Sun, Jan 22, 2017 at 2:58 PM, Michael Leung <gbcbooksmj at gmail.com> wrote:
> i think the following error would indicate why ipv6 did not work for me
> "Connection MTU (1268) is not sufficient for IPv6 (1280)"
>
> for now , i still dont know why it gave out a low value for interface mtu
>
> here is the mtu setting on my ocserv.conf
>
> auth = "plain[/etc/ocserv/passwd]"
> use-occtl = true
> banner = "Welcome ocs server"
> max-clients = 16
> max-same-clients = 2
> tcp-port = 5551
> udp-port = 5551
> keepalive = 32400
> dpd = 240
> mobile-dpd = 1800
> ###################
> try-mtu-discovery = true
> ###################
> server-cert = /etc/ocserv/certs/anyconnect.cert
> server-key = /etc/ocserv/private/prikey.pem
> tls-priorities = "NORMAL:%SERVER_PRECEDENCE:%COMPAT"
> auth-timeout = 40
> cookie-timeout = 86400
> rekey-time = 172800
> rekey-method = ssl
> disconnect-script = /usr/bin/myscript
> use-utmp = true
> use-dbus = false
> pid-file = /var/run/ocserv.pid
> socket-file = /var/run/ocserv-socket
> run-as-user = root
> run-as-group = root
> device = vpns
> default-domain = ocserv.eu.org.
> ipv4-network = 10.200.254.0
> ipv4-netmask = 255.255.255.128
> dns = 9.9.9.9
> dns = 2.2.2.2
> ipv6-network = 2001:470:f916:ffff::
> ipv6-prefix = 64
> ping-leases = false
> ###################
> mtu = 1320
> ###################
> config-per-user = /etc/ocserv/config-per-user
> config-per-group = /etc/ocserv/config-per-group
>
> On Sat, Jan 21, 2017 at 11:45 PM, Kevin Cernekee <cernekee at gmail.com> wrote:
>>
>> On Sat, Jan 21, 2017 at 5:52 AM, Goodman Leung <gbcbooksmj at gmail.com>
>> wrote:
>> > does any one have ipv6 work on ocserv ?
>> >
>> > i add configure "ipv6-network = 2001:470:c19d:xxxx:xxxx::/64"
>> >
>> > and from the debug log output
>> >
>> >   assigned IPv6: 2001:470:f91d:c15c:0:74:f141:e500
>> >
>> > ipv6 address had been assigned, from when i check my client side , it
>> > did not found ipv6 address on the tun interface
>>
>> It's working for me, using explicit-ipv6 to provide a /128 to specific
>> clients.
>>
>> You might want to run the client with --dump-http-traffic and look for
>> these headers:
>>
>> X-CSTP-Address-Type: IPv6,IPv4
>> X-CSTP-Address-IP6: 2001:470:f91d:c15c:0:74:f141:e500/128
>>
>> If your ipv6-network (i.e. the delegation you received from your ISP)
>> is only a /64, you can try ipv6-subnet-prefix = 128.  Ideally you'd
>> want to get a /48 or /56 from your ISP, and then hand out a /64 to
>> each VPN client.
>
>


From hiharsh at gmail.com  Mon Jan 23 11:50:59 2017
From: hiharsh at gmail.com (harsh P)
Date: Mon, 23 Jan 2017 14:50:59 -0500
Subject: OpenConnect as a non-root user.
Message-ID: <CA+mubHo_34X8q16gDGeiKToBR51XLcBTeC3+wozf=wvUzzmH1g@mail.gmail.com>

HI,
I followed the steps and launched openConnect to connect to my VPNServer.
I got the error "Failed to bind localTun devices (TUNSETIFF)" .
Operation not permitted. Openconnect must be running as a root user.

My ultimate goal is to launch openconnect from C++ code using system
command as a non-root user.
I believe that people must have used openConnect with user name
password supplied as an argument or username passowrd information
buried in a script which will be passed as an argument.

Please let me know how do I achieve this?

-- 
Thanks & Regards
Harsh


From nielspeen at icloud.com  Tue Jan 24 08:39:36 2017
From: nielspeen at icloud.com (Niels Peen)
Date: Tue, 24 Jan 2017 17:39:36 +0100
Subject: Radius: Acct-Session-Id missing from Interim-Updates?
Message-ID: <83193460-F84A-4403-A592-30D40CE1EE83@icloud.com>

Hi Nikos,

I noticed ocserv 0.11.6 includes an Acct-Session-Id with the Start packet, but not with the Interim-Update packets. Is this the correct behaviour? If so, is it possible to (optionally) add the Acct-Session-Id to all accounting packets? 

(If I understand RFC2866 correctly the Acct-Session-Id is required for all accounting requests.)

Thanks,
Niels

(47) Received Accounting-Request Id 33 from XYZ:6183 to ABC:1813 length 222
(47)   Acct-Status-Type = Start
(47)   Connect-Info = ?someclient"
(47)   NAS-Identifier = ?XYZ"
(47)   NAS-IP-Address = ABC
(47)   User-Name = "niels"
(47)   Service-Type = Framed-User
(47)   Framed-Protocol = PPP
(47)   Calling-Station-Id = ?DEF"
(47)   Acct-Session-Id = "54K6X16YQ+62vq0RNBYGavKuiR5nKlQi/tvqte5wl3g="
(47)   Acct-Authentic = RADIUS
(47)   NAS-Port = 18632
(47)   Acct-Delay-Time = 0


(48) Received Accounting-Request Id 185 from XYZ:53953 to ABC:1813 length 131
(48)   Acct-Status-Type = Interim-Update
(48)   NAS-Identifier = ?XYZ"
(48)   NAS-IP-Address = ABC
(48)   User-Name = "niels"
(48)   Service-Type = Framed-User
(48)   Framed-Protocol = PPP
(48)   Framed-IP-Address = 10.252.244.110
(48)   Acct-Input-Octets = 0
(48)   Acct-Output-Octets = 0
(48)   Acct-Input-Gigawords = 0
(48)   Acct-Output-Gigawords = 0
(48)   NAS-Port = 18636
(48)   Acct-Delay-Time = 0





From dustin.hartung at gmail.com  Tue Jan 24 09:28:50 2017
From: dustin.hartung at gmail.com (Dustin Hartung)
Date: Tue, 24 Jan 2017 11:28:50 -0600
Subject: Failed to obtain WebVPN cookie
Message-ID: <CAMedPwXovK3YKi8x4S6J6FzMNnJOrDZ-Nh_L1LKOL1JqZ45eGQ@mail.gmail.com>

I am trying to use openconnect on my Mac to connect to a Junos vpn.
Below is my command and the response i am getting.  I am not sure
where to go from here.  I downloaded generic tncc-wrapper.py from
Github.  Does it need to be modified?


openconnect --juniper --useragent 'Mozilla/5.0 (Linux) Firefox'
--csd-wrapper=tncc-wrapper.py https://vpn.mycompany.com/mycompany
WARNING: Juniper Network Connect support is experimental.
It will probably be superseded by Junos Pulse support.
GET https://vpn.mycompany.com/mycompany
Connected to https://vpn.mycompany.com/mycompany:443
SSL negotiation with vpn.mycompany.com
Connected to HTTPS on vpn.mycompany.com
Got HTTP response: HTTP/1.1 302 Found
GET https://vpn.mycompany.com/dana-na/auth/url_default/welcome.cgi
SSL negotiation with vpn.mycompany.com
Connected to HTTPS on vpn.mycompany.com
Failed to obtain WebVPN cookie

Thanks
Dusitn


From dlenski at gmail.com  Tue Jan 24 11:12:40 2017
From: dlenski at gmail.com (Daniel Lenski)
Date: Tue, 24 Jan 2017 11:12:40 -0800
Subject: Failed to obtain WebVPN cookie
In-Reply-To: <CAMedPwXovK3YKi8x4S6J6FzMNnJOrDZ-Nh_L1LKOL1JqZ45eGQ@mail.gmail.com>
References: <CAMedPwXovK3YKi8x4S6J6FzMNnJOrDZ-Nh_L1LKOL1JqZ45eGQ@mail.gmail.com>
Message-ID: <CAOw_LSHhQJTs_gdyuL40OS6UteaGHnE2gcFnoRc88jxf=LOVSA@mail.gmail.com>

On Tue, Jan 24, 2017 at 9:28 AM, Dustin Hartung
<dustin.hartung at gmail.com> wrote:
> I am trying to use openconnect on my Mac to connect to a Junos vpn.
> Below is my command and the response i am getting. I am not sure
> where to go from here.  I downloaded generic tncc-wrapper.py from
> Github.  Does it need to be modified?

Are you sure that TNCC is the problem here?

You should run with --dump to show all the HTTP traffic that
openconnect is sending and receiving. OC is probably getting hung up
on an authentication form that it doesn't understand. OC's Juniper
auth support is necessarily incomplete, because Juniper authentication
consists of totally free-form web pages.

Logging should make this clear.

Dan


From dustin.hartung at gmail.com  Tue Jan 24 12:16:39 2017
From: dustin.hartung at gmail.com (Dustin Hartung)
Date: Tue, 24 Jan 2017 14:16:39 -0600
Subject: Failed to obtain WebVPN cookie
In-Reply-To: <CAOw_LSHhQJTs_gdyuL40OS6UteaGHnE2gcFnoRc88jxf=LOVSA@mail.gmail.com>
References: <CAMedPwXovK3YKi8x4S6J6FzMNnJOrDZ-Nh_L1LKOL1JqZ45eGQ@mail.gmail.com>
 <CAOw_LSHhQJTs_gdyuL40OS6UteaGHnE2gcFnoRc88jxf=LOVSA@mail.gmail.com>
Message-ID: <CAMedPwUv7Pt0okGH2WdykJNavD-ABBnQJ0taZfrrNs64Oc5mdw@mail.gmail.com>

Thank you for the response and tip.  I tried as you said - running it
with --dump using a user agent and without as there appears to be
different requirements/rules depending on the device type- the results
are below:

________________________________________________________________________________
With a Mobile UserAgent:

dhrmbp1:~ dh$  openconnect --juniper --useragent  'JunosPulseiPhone
Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X)
AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9B206
JunosPulse(Version-3.2.2.21349)iPhone' --csd-wrapper=tncc-wrapper.py
--dump vpn.mycompany.com/mycompany

WARNING: Juniper Network Connect support is experimental.
It will probably be superseded by Junos Pulse support.
GET https://vpn.mycompany.com/mycompany
Attempting to connect to server 65.210.57.16:443
Connected to 65.210.57.16:443
SSL negotiation with vpn.mycompany.com
Connected to HTTPS on vpn.mycompany.com
> GET /mycompany HTTP/1.1
> Host: vpn.mycompany.com
> User-Agent: JunosPulseiPhone Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9B206 JunosPulse(Version-3.2.2.21349)iPhone
> Connection: close
> NCP-Version: 3
>
Got HTTP response: HTTP/1.1 302 Found
Location: https://vpn.mycompany.com/dana-na/auth/url_default/welcome.cgi
Content-Type: text/html; charset=utf-8
Set-Cookie: DSSIGNIN=url_default; path=/dana-na/; expires=Thu,
31-Dec-2037 00:00:00 GMT; secure
Set-Cookie: DSIVS=; path=/; expires=Thu, 01 Jan 1970 22:00:00 GMT; secure
Set-Cookie: DSSignInURL=/mycompany; path=/; secure
Connection: close
Content-Length: 0
HTTP body length:  (0)
GET https://vpn.mycompany.com/dana-na/auth/url_default/welcome.cgi
SSL negotiation with vpn.mycompany.com
Connected to HTTPS on vpn.mycompany.com
> GET /dana-na/auth/url_default/welcome.cgi HTTP/1.1
> Host: vpn.mycompany.com
> User-Agent: JunosPulseiPhone Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9B206 JunosPulse(Version-3.2.2.21349)iPhone
> Cookie: DSSIGNIN=url_default; DSSignInURL=/mycompany
> Connection: close
> NCP-Version: 3
>
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: DSCheckBrowser=; path=/; expires=Sat, 27-Jan-2007 19:57:58
GMT; secure
Set-Cookie: DSPREAUTH=592a86ac%3AxrGHWPieAgABAAAAocszTLLg%2B11ic1XMpqoG6PAPgy47Untj5pYv%2BijnNUxzb1APVPhG6a7kFQUp8kc6ULtZXpyBkTyalepHwrqe70hZNJGp2cKX0ahkf5oW%2BRyxaNbvENdzcxJdKu27Dtmub9CoqoFY1%2BBBpdScgLv8ZAAiYwRsQISaKGPEYOk4oSUDRoHwIFDrhn1p5dxA9QWUuN3oxdrGmSPTmr5HMhKJyOl%2BBVJO%2B2NaA7zofTpelJz1W5OsKRAMfIDqsqQeZtgMofagWm7tPEcdPdNxR%2FWvxQlyY7ITrCGwE0xrclPt0E4R2QdcBIOgmEiup2G6ii6rovUfX%2BqxG0aYx3Z9Z0U2WLfVBeUeMrxsegvybc1ebQoIDuLIclxxasKxyOtxZcVa;
path=/dana-na/; expires=Wed,  24-Jan-2018 14:57:58 GMT; secure
Set-Cookie: DSHCSTARTED=1; path=/dana-na/; secure
Date: Tue, 24 Jan 2017 19:57:58 GMT
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
X-Frame-Options: SAMEORIGIN
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
< <html><head>
< <meta http-equiv="Content-Language"/>
< <meta http-equiv="Content-Type" content="text/html"/>
< <meta name=robots content="none"/>
< <title>mycompany Secure Access Service - PleaseWait</title>
<
< <link href="/dana-na/css/ds_mobile_common_18dbed3d1620b09fa1f569d8686f36286e503cfa396ed1b07cf35ae4b7454281.css"
type="text/css" rel="stylesheet"/>
< <link href="/dana-na/css/ds_mobile_safari_18dbed3d1620b09fa1f569d8686f36286e503cfa396ed1b07cf35ae4b7454281.css"
type="text/css" rel="stylesheet"/>
< <meta name="viewport" content="width=device-width,
initial-scale=1.0, maximum-scale=1.0, user-scalable=no"/>
< <meta name="format-detection" content="telephone=no"/>
<
< <script type="text/javascript">function hideUrlBar() {
<     // Hides URL Bar on the iPhone
<     var minHeight = 0;
<
<     if (window.innerHeight) {
<         minHeight = window.innerHeight + 60;
<     }
<     document.body.style.minHeight = minHeight + 'px';
<     document.getElementById('main_div').style.minHeight = minHeight + 'px';
<
<     setTimeout(function()
<     {
<         window.scrollTo(0,1);
<     }, 100);
< }
<
< addEventListener("load", function() { setTimeout(hideUrlBar, 0); }, false);
< function textFieldGetFocus(field) {
<   document.getElementById(field).focus();
< }
< </script>
<
< </head>
<
<
< <script language="JavaScript">
< var userAgentTypeApple = "1";
< var userAgentTypeAndroid = "";
< function OnStart()
< {
<     if(userAgentTypeApple == "1") {
<         window.location = "IVEAction://startHC";
<         Browser.redirect("IVEAction://startHC");
<     }
<     else if(userAgentTypeAndroid == "1"){
<         HTMLOUT.showHTML("my APP");
<     }
<     else {
<         document.cookie = "DSCheckBrowser=" + escape('none') + ";
path=/;secure";
<         var href = window.location.href;
<         window.location = href;
<     }
< }
< </script>
<
< <body onload="OnStart();"><table
id="table_PleaseWait-mobile-webkit_1" border="0" cellpadding="10"
cellspacing="0">
<         <tr><td><small><b>Loading Components...</b></small></td></tr>
< </table>
<
< <table id="table_PleaseWait-mobile-webkit_2" cellpadding="2"
cellspacing="0" border="0" width="100%">
<     <tr>
<         <td>&nbsp;</td>
<         <td width="100%"><span><div id="hc">Host Checker</div></span></td>
<     </tr>
< </table></body>
<
< <input id="serverdetails_1" type="hidden" name="serverdetails"
value="interval=0;process_timeout=90;cert_md5=1f9ab4221d578a51b6c73b93c06149fe;hash_key=06f23f73c64c6df8a8a64ecbe431b75d166d46d1;logging=1;locale=en">
< </html>
<
Failed to obtain WebVPN cookie

________________________________________________________________________________
With No UserAgent:

openconnect --juniper --dump --csd-wrapper=tncc-wrapper.py
vpn.mycompany.com/mycompany
WARNING: Juniper Network Connect support is experimental.
It will probably be superseded by Junos Pulse support.
GET https://vpn.mycompany.com/mycompany
Attempting to connect to server 65.210.57.16:443
Connected to 65.210.57.16:443
SSL negotiation with vpn.mycompany.com
Connected to HTTPS on vpn.mycompany.com
> GET /mycompany HTTP/1.1
> Host: vpn.mycompany.com
> User-Agent: Open AnyConnect VPN Agent v7.08
> Connection: close
> NCP-Version: 3
>
Got HTTP response: HTTP/1.1 302 Found
Location: https://vpn.mycompany.com/dana-na/auth/url_default/welcome.cgi
Content-Type: text/html; charset=utf-8
Set-Cookie: DSSIGNIN=url_default; path=/dana-na/; expires=Thu,
31-Dec-2037 00:00:00 GMT; secure
Set-Cookie: DSIVS=; path=/; expires=Thu, 01 Jan 1970 22:00:00 GMT; secure
Set-Cookie: DSSignInURL=/mycompany; path=/; secure
Connection: close
Content-Length: 0
HTTP body length:  (0)
GET https://vpn.mycompany.com/dana-na/auth/url_default/welcome.cgi
SSL negotiation with vpn.mycompany.com
Connected to HTTPS on vpn.mycompany.com
> GET /dana-na/auth/url_default/welcome.cgi HTTP/1.1
> Host: vpn.mycompany.com
> User-Agent: Open AnyConnect VPN Agent v7.08
> Cookie: DSSIGNIN=url_default; DSSignInURL=/mycompany
> Connection: close
> NCP-Version: 3
>
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: DSHCSTARTED=1; path=/dana-na/; secure
Date: Tue, 24 Jan 2017 20:05:18 GMT
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
X-Frame-Options: SAMEORIGIN
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
<
< <html>
< <head>
< <meta http-equiv="Content-Language">
< <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
< <title>mycompany Secure Access Service - PleaseWait</title>
< <script src="/dana-na/css/ds_18dbed3d1620b09fa1f569d8686f36286e503cfa396ed1b07cf35ae4b7454281.js"></script>
< <meta name="robots" content="none">
< <script>
<         WriteCSS();
< </script>
< <noscript>
< <link rel="stylesheet"
href="/dana-na/css/ds_18dbed3d1620b09fa1f569d8686f36286e503cfa396ed1b07cf35ae4b7454281.css"></link>
< </noscript>
< <script src="/dana-na/js/checkbrowser_18dbed3d1620b09fa1f569d8686f36286e503cfa396ed1b07cf35ae4b7454281.js"></script>
< <script src="/dana-na/js/clientSetup_18dbed3d1620b09fa1f569d8686f36286e503cfa396ed1b07cf35ae4b7454281.js"></script><script
src="/dana-na/js/intermediate_18dbed3d1620b09fa1f569d8686f36286e503cfa396ed1b07cf35ae4b7454281.js"></script>
< <script>
<
< var error_message = '';
< var start_status = 1;
< var check_browser = new CheckBrowser();
< var g_delivery = '';
< var g_checkbCookieSet = false;
< var g_HCLoading = 'Host Checker';
< var g_isUAC = '0';
<
< function initBulb (component)
< {
< document.getElementById(component + 'bulb').style.color = "#808080";
< }
<
< function setSucceeded(component)
< {
<     document.getElementById(component + 'bulb').style.color = "#03CA08";
<     setStatus(1);
< }
<
< function setFailed(component)
< {
<     document.getElementById(component + 'bulb').style.color = "#990000";
<     setStatus(0);
< }
<
< function setStarted(component)
< {
< document.getElementById(component).style.fontWeight = "bold";
< }
<
< function setFinished(component)
< {
< document.getElementById(component).style.fontWeight = "normal";
< }
< function gowelcome()
< {
<     if (g_delivery != '') {
<         setCheckBrowserCookie ();
<     }
< if (getStatus()) {
< document.getElementById('endstatus').innerHTML = 'Components loaded
successfully';
<         var url = window.location;
<         if (dsIsVista() || dsIsWinXP()) {
<             try {
<                 var SetupCtrl;
<                 if (document.deliveryType == 'java') {
<                     var doc = getIFrameDocument("controlframe");
<                     if (typeof(doc) == "undefined") {
<                         return false;
<                     }
<                     SetupCtrl = doc.getElementById("NeoterisSetup");
<                 }
<                 else if (document.deliveryType == 'activex') {
<                     SetupCtrl = document.getElementById("NeoterisSetup");
<                 }
<                 if (SetupCtrl != "undefined") {
<                     var data = SetupCtrl.retrieveData("HCDATA");
<                     if (data && data.indexOf("AED={") != -1) {
<                         // AED getting initialised
<                         var aedParams = aedParseProgressString (data);
<                         var aedInitComplete = 0;
<                         if (aedParams.statusInitialization ==
gAedProgress.SUCCESS
||aedParams.statusInitialization==gAedProgress.FAIL) {
<                             if (aedParseParam(data, 'HSStatus:')) {
<                                 aedInitComplete = 1;
<                             }
<                         }
<                         if (!aedInitComplete) {
<                             if (url.toString().indexOf('?') == -1) {
<                                 url += "?type=inter";
<                             }
<                             else {
<                                 url += "&type=inter";
<                             }
<                         }
<                     }
<                 }
<             }
<             catch (e) {
<             }
<         }
<         window.location = url;
< }
< else  {
< document.getElementById('endstatus').innerHTML = error_message;
<    setTimeout("window.location = window.location;", 5000);
<     }
< }
<
< function setCCSucceeded()
< {
< setSucceeded('cc');
< }
< function setHCSucceeded()
< {
< setSucceeded('hc');
< }
<
< function getComponent(component)
< {
<     return document.getElementById(component + 'bulb');
< }
<
< function failComponents()
< {
<     if (getComponent('hc')) setFailed('hc');
<     if (getComponent('cc')) setFailed('cc');
<     if (getComponent('ep')) setFailed('ep');
< }
<
< function setStatus(s)
< {
<     start_status = s;
< }
< function getStatus()
< {
<     return start_status;
< }
< function setErrorMessage(aMsg)
< {
<     error_message = aMsg;
< }
<
< function loadIframe(iframeName, url) {
<    var doc = getIFrameDocument(iframeName);
<    if (typeof(doc) == "undefined") {
<     return false;
<    }
<    doc.location.href = url;
<    return true;
< }
<
< function getIFrameDocument(iframeName) {
<     var fr;
<     var frWindow;
<     var frDocument;
<     if ( window.frames && window.frames[iframeName] ) {
<         frWindow = window.frames[iframeName];
<     }else if (document.getElementById(iframeName) ) {
<         frWindow = document.getElementById(iframeName).contentWindow;
<     }else {
<         return ;
<     }
<
<     fr = document.getElementById(iframeName);
<     if (frWindow && frWindow.document)
<         frDocument = frWindow.document;
<     else if (fr && fr.contentDocument)
<         frDocument = fr.contentDocument;
<
<     return frDocument;
< }
<
< function checkb() {
<     g_delivery = 'none';    g_delivery = 'none';
<     if (dsIsActiveXEnabled()){
<         g_delivery = 'activex';
<     }else if (dsIsJavaEnabled()) {
<         g_delivery = 'java';
<     }    document.deliveryType = g_delivery;
<     return g_delivery;
< }
<
< // Redirect to CGI to download the Setup Client .exe
< function redirectToSetupCGI() {
<     var href = window.location.href;
<     var redirectURL = "/dana-na/setup/download.cgi?r=" + escape(href);
<     if (dsIsMac()) {
<         redirectURL = redirectURL + "&platform=Macintosh";
<     }
<     window.location = redirectURL;
< }
<
< function loadControlFrame()
< {
<     try {
<         loadIframe ('controlframe', window.location);
<     } catch (e) {
<         failComponents();
<         setTimeout("gowelcome();", 0);
<     }
< }
<
< function setCheckBrowserCookie () {
<     if (g_checkbCookieSet == false) {
<         document.cookie = "DSCheckBrowser=" + escape(g_delivery) +
"; path=/;secure";
<         g_checkbCookieSet = true;
<     }
< }
<
< function submitBrowserInfo() {
<     setCheckBrowserCookie ();
<     if (g_delivery == 'none') {
<         setErrorMessage ('Your browser does not support either
ActiveX controls or Java applets. Please contact your
administrator.');
<         failComponents ();
<         gowelcome();
<     } else {
<         loadControlFrame();
<     }
< }
<
< function startOnLoad()
< {
<  var c = checkb();
<  if ((c == 'none') && (dsIsVista() || dsIsWinXP() || dsIsMac())) {
<      failComponents ();
<      setTimeout("redirectToSetupCGI();", 7000);
<      return;
<  }
<     setTimeout ("submitBrowserInfo();", 2000);}
< </script>
<
<
<
< <script>
< <!--
< if (window.top != self) {
< top.location = location;
< }
< //--></script>
< </head>
<
< <body bgcolor="#FFFFFF" color="#000000" link="#3366CC"
vlink="#CC6699" alink="#3366CC" leftmargin="0" topmargin="0"
rightmargin="0" marginwidth="0" marginheight="0"
onload="startOnLoad()" >
<
<
< <table id="table_PleaseWait_1" border="0" width="100%"
cellspacing="0" cellpadding="3">
<         <tr>
<             <td bgcolor="E3E3E3"><img border="0"
src="/dana-na/auth/welcome.cgi?p=logo" alt="Logo"></td>
<        <td bgcolor="E3E3E3" align="right">&nbsp;</td>
<
<         </tr>
< </table>
< <table id="table_PleaseWait_2" cellpadding="0" cellspacing="0"
border="0" width="100%">
<         <tr>
<                 <td bgcolor="#000000" colspan="2"><img border="0"
src="/dana-na/imgs/space.gif" width="1" height="1"></td>
<         </tr>
< </table>
< <blockquote>
<         <table id="table_PleaseWait_3" border="0" cellpadding="2"
cellspacing="0">
< <tr><td nowrap ><font face="verdana,sans-serif" size="3"><b>Loading
Components...</b></font></td></tr>
< <tr><td nowrap ><font face="verdana,sans-serif" size="2">Please
wait. This may take several minutes.</font></td></tr>
<         </table>
<
< <table id="table_PleaseWait_4" cellpadding="4" cellspacing="0"
border="0" width="100%"> <tr>
< <td><img src="/dana-na/imgs/space.gif" width="30" height="1"></td>
< <td><span style="font-weight:bold; color:#808080; font-size:135%;"
id="hcbulb">&#0149;</span></td>
< <td width="100%"><span><div id="hc">Host Checker</div></span></td>
< </tr> <tr>
< <td> </td>
< <td> </td>
< <tr>
<         <table id="table_PleaseWait_5" border="0" cellpadding="2"
cellspacing="0">
< <tr><td nowrap ><font face="verdana,sans-serif" size="2">
<         <div id="continue">If an error prevents a component from
loading properly, you can <a href="javascript:void(0)"
onclick="javascript:gowelcome();return false;">click here</a> to
continue. Not all functionality may be available.
</div></font></td></tr>
<         </table>
< </tr>
< <tr>
< <td><img src="/dana-na/imgs/space.gif" width="30" height="1"></td>
< </tr>
< <tr>
< <td><img src="/dana-na/imgs/space.gif" width="30" height="1"></td>
< </tr>
<         <table id="table_PleaseWait_6" border="0" cellpadding="2"
cellspacing="0">
< <tr><td nowrap ><font face="verdana,sans-serif" size="2"><div
id="endstatus"></div></font></td></tr>
<         </table>
< </table>
< </blockquote>
< <OBJECT classid="clsid:F27237D7-93C8-44C2-AC6E-D6057B9A918F"
<  id=NeoterisSetup
codebase="\dana-cached\sc\JuniperSetupClient.cab#version=2,1,1,1"
< width=0 height=0 >
< </object><p align="left"><iframe id="controlframe"
name="controlframe" src="/dana-na/html/blank.html" width="2"
height="2" frameborder="0" scrolling="NO"></iframe></p>
<
< </body>
<
< </html>
No DSPREAUTH cookie; not attempting TNCC
Failed to obtain WebVPN cookie
Dustin L Hartung


On Tue, Jan 24, 2017 at 1:12 PM, Daniel Lenski <dlenski at gmail.com> wrote:
> On Tue, Jan 24, 2017 at 9:28 AM, Dustin Hartung
> <dustin.hartung at gmail.com> wrote:
>> I am trying to use openconnect on my Mac to connect to a Junos vpn.
>> Below is my command and the response i am getting. I am not sure
>> where to go from here.  I downloaded generic tncc-wrapper.py from
>> Github.  Does it need to be modified?
>
> Are you sure that TNCC is the problem here?
>
> You should run with --dump to show all the HTTP traffic that
> openconnect is sending and receiving. OC is probably getting hung up
> on an authentication form that it doesn't understand. OC's Juniper
> auth support is necessarily incomplete, because Juniper authentication
> consists of totally free-form web pages.
>
> Logging should make this clear.
>
> Dan


From dlenski at gmail.com  Tue Jan 24 13:17:32 2017
From: dlenski at gmail.com (Daniel Lenski)
Date: Tue, 24 Jan 2017 13:17:32 -0800
Subject: Failed to obtain WebVPN cookie
In-Reply-To: <CAMedPwUv7Pt0okGH2WdykJNavD-ABBnQJ0taZfrrNs64Oc5mdw@mail.gmail.com>
References: <CAMedPwXovK3YKi8x4S6J6FzMNnJOrDZ-Nh_L1LKOL1JqZ45eGQ@mail.gmail.com>
 <CAOw_LSHhQJTs_gdyuL40OS6UteaGHnE2gcFnoRc88jxf=LOVSA@mail.gmail.com>
 <CAMedPwUv7Pt0okGH2WdykJNavD-ABBnQJ0taZfrrNs64Oc5mdw@mail.gmail.com>
Message-ID: <CAOw_LSGZwiQRV=FB2mhnV5gDHPCbzW7FbFcQUYscOLk-DuO6TA@mail.gmail.com>

On Tue, Jan 24, 2017 at 12:16 PM, Dustin Hartung
<dustin.hartung at gmail.com> wrote:
> Thank you for the response and tip.  I tried as you said - running it
> with --dump using a user agent and without as there appears to be
> different requirements/rules depending on the device type- the results
> are below:

Yes, this is pretty typical for Juniper. It appears that your VPN uses
authentication forms that are larded up with JavaScript.

You might also want to try --useragent ncsvc, which spoofs the UA of
Juniper's official desktop client, and often results in a simpler and
easier-to-parse HTML page.

For an example of where this works: I use a VPN which authenticates
with "SecureMatrix". With a mobile/desktop UA, it generates a pattern
of images using Java or ActiveX applets and I have to enter the
numbers shown in the applet? but with "ncsvc" it generates a simple
pure-text page that makes it easy to scrape and login automatically
with a Python script (https://github.com/dlenski/smxlogin).

Also, keep in mind that you can do "manual" external authentication as
described in the OpenConnect manual:
http://www.infradead.org/openconnect/juniper.html

Basically, just login via the web interface, then show the DSID cookie
in your browser, and run:

    $ openconnect --juniper -C "DSID=foobar12345" vpn.example.com

-Dan


From dustin.hartung at gmail.com  Tue Jan 24 13:53:56 2017
From: dustin.hartung at gmail.com (Dustin Hartung)
Date: Tue, 24 Jan 2017 15:53:56 -0600
Subject: Failed to obtain WebVPN cookie
In-Reply-To: <CAOw_LSGZwiQRV=FB2mhnV5gDHPCbzW7FbFcQUYscOLk-DuO6TA@mail.gmail.com>
References: <CAMedPwXovK3YKi8x4S6J6FzMNnJOrDZ-Nh_L1LKOL1JqZ45eGQ@mail.gmail.com>
 <CAOw_LSHhQJTs_gdyuL40OS6UteaGHnE2gcFnoRc88jxf=LOVSA@mail.gmail.com>
 <CAMedPwUv7Pt0okGH2WdykJNavD-ABBnQJ0taZfrrNs64Oc5mdw@mail.gmail.com>
 <CAOw_LSGZwiQRV=FB2mhnV5gDHPCbzW7FbFcQUYscOLk-DuO6TA@mail.gmail.com>
Message-ID: <CAMedPwWvaXOnOW6w=QgZ9PCxtyWAd2sGMxhf+WAs32GVpCaTMw@mail.gmail.com>

the ncsvc switch didnt seem to do anything different....  In terms of
the DSID cookie - i am exactly sure how to generate it.  We use the
junos client on Macs/iPhones and the Network Connect client in
windows.  We dont necessarily login from a browser.  If i do try to
hit that page from a web browser it shows loading components *Host
Checker"  and if i view the cookies i see the following:

opentoken
DSSigninURL
DSSIGNIN
DSPREAUTH
DSLAUNCHURL
DSHCSTARTED


-------------Ran with nscvc -------------

openconnect --juniper --useragent ncsvc --dump
https://vpn.mycompany.com/mycompany
WARNING: Juniper Network Connect support is experimental.
It will probably be superseded by Junos Pulse support.
GET https://vpn.mycompany.com/mycompany
Attempting to connect to server 65.210.57.16:443
Connected to 65.210.57.16:443
SSL negotiation with vpn.mycompany.com
Connected to HTTPS on vpn.mycompany.com
> GET /mycompany HTTP/1.1
> Host: vpn.mycompany.com
> User-Agent: ncsvc
> Connection: close
> NCP-Version: 3
>
Got HTTP response: HTTP/1.1 302 Found
Location: https://vpn.mycompany.com/dana-na/auth/url_default/welcome.cgi
Content-Type: text/html; charset=utf-8
Set-Cookie: DSSIGNIN=url_default; path=/dana-na/; expires=Thu,
31-Dec-2037 00:00:00 GMT; secure
Set-Cookie: DSIVS=; path=/; expires=Thu, 01 Jan 1970 22:00:00 GMT; secure
Set-Cookie: DSSignInURL=/mycompany; path=/; secure
Connection: close
Content-Length: 0
HTTP body length:  (0)
GET https://vpn.mycompany.com/dana-na/auth/url_default/welcome.cgi
SSL negotiation with vpn.mycompany.com
Connected to HTTPS on vpn.mycompany.com
> GET /dana-na/auth/url_default/welcome.cgi HTTP/1.1
> Host: vpn.mycompany.com
> User-Agent: ncsvc
> Cookie: DSSIGNIN=url_default; DSSignInURL=/mycompany
> Connection: close
> NCP-Version: 3
>
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: DSHCSTARTED=1; path=/dana-na/; secure
Date: Tue, 24 Jan 2017 21:37:46 GMT
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
X-Frame-Options: SAMEORIGIN
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
<
< <html>
< <head>
< <meta http-equiv="Content-Language">
< <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
< <title>mycompany Secure Access Service - PleaseWait</title>
< <script src="/dana-na/css/ds_18dbed3d1620b09fa1f569d8686f36286e503cfa396ed1b07cf35ae4b7454281.js"></script>
< <meta name="robots" content="none">
< <script>
<         WriteCSS();
< </script>
< <noscript>
< <link rel="stylesheet"
href="/dana-na/css/ds_18dbed3d1620b09fa1f569d8686f36286e503cfa396ed1b07cf35ae4b7454281.css"></link>
< </noscript>
< <script src="/dana-na/js/checkbrowser_18dbed3d1620b09fa1f569d8686f36286e503cfa396ed1b07cf35ae4b7454281.js"></script>
< <script src="/dana-na/js/clientSetup_18dbed3d1620b09fa1f569d8686f36286e503cfa396ed1b07cf35ae4b7454281.js"></script><script
src="/dana-na/js/intermediate_18dbed3d1620b09fa1f569d8686f36286e503cfa396ed1b07cf35ae4b7454281.js"></script>
< <script>
<
< var error_message = '';
< var start_status = 1;
< var check_browser = new CheckBrowser();
< var g_delivery = '';
< var g_checkbCookieSet = false;
< var g_HCLoading = 'Host Checker';
< var g_isUAC = '0';
<
< function initBulb (component)
< {
< document.getElementById(component + 'bulb').style.color = "#808080";
< }
<
< function setSucceeded(component)
< {
<     document.getElementById(component + 'bulb').style.color = "#03CA08";
<     setStatus(1);
< }
<
< function setFailed(component)
< {
<     document.getElementById(component + 'bulb').style.color = "#990000";
<     setStatus(0);
< }
<
< function setStarted(component)
< {
< document.getElementById(component).style.fontWeight = "bold";
< }
<
< function setFinished(component)
< {
< document.getElementById(component).style.fontWeight = "normal";
< }
< function gowelcome()
< {
<     if (g_delivery != '') {
<         setCheckBrowserCookie ();
<     }
< if (getStatus()) {
< document.getElementById('endstatus').innerHTML = 'Components loaded
successfully';
<         var url = window.location;
<         if (dsIsVista() || dsIsWinXP()) {
<             try {
<                 var SetupCtrl;
<                 if (document.deliveryType == 'java') {
<                     var doc = getIFrameDocument("controlframe");
<                     if (typeof(doc) == "undefined") {
<                         return false;
<                     }
<                     SetupCtrl = doc.getElementById("NeoterisSetup");
<                 }
<                 else if (document.deliveryType == 'activex') {
<                     SetupCtrl = document.getElementById("NeoterisSetup");
<                 }
<                 if (SetupCtrl != "undefined") {
<                     var data = SetupCtrl.retrieveData("HCDATA");
<                     if (data && data.indexOf("AED={") != -1) {
<                         // AED getting initialised
<                         var aedParams = aedParseProgressString (data);
<                         var aedInitComplete = 0;
<                         if (aedParams.statusInitialization ==
gAedProgress.SUCCESS
||aedParams.statusInitialization==gAedProgress.FAIL) {
<                             if (aedParseParam(data, 'HSStatus:')) {
<                                 aedInitComplete = 1;
<                             }
<                         }
<                         if (!aedInitComplete) {
<                             if (url.toString().indexOf('?') == -1) {
<                                 url += "?type=inter";
<                             }
<                             else {
<                                 url += "&type=inter";
<                             }
<                         }
<                     }
<                 }
<             }
<             catch (e) {
<             }
<         }
<         window.location = url;
< }
< else  {
< document.getElementById('endstatus').innerHTML = error_message;
<    setTimeout("window.location = window.location;", 5000);
<     }
< }
<
< function setCCSucceeded()
< {
< setSucceeded('cc');
< }
< function setHCSucceeded()
< {
< setSucceeded('hc');
< }
<
< function getComponent(component)
< {
<     return document.getElementById(component + 'bulb');
< }
<
< function failComponents()
< {
<     if (getComponent('hc')) setFailed('hc');
<     if (getComponent('cc')) setFailed('cc');
<     if (getComponent('ep')) setFailed('ep');
< }
<
< function setStatus(s)
< {
<     start_status = s;
< }
< function getStatus()
< {
<     return start_status;
< }
< function setErrorMessage(aMsg)
< {
<     error_message = aMsg;
< }
<
< function loadIframe(iframeName, url) {
<    var doc = getIFrameDocument(iframeName);
<    if (typeof(doc) == "undefined") {
<     return false;
<    }
<    doc.location.href = url;
<    return true;
< }
<
< function getIFrameDocument(iframeName) {
<     var fr;
<     var frWindow;
<     var frDocument;
<     if ( window.frames && window.frames[iframeName] ) {
<         frWindow = window.frames[iframeName];
<     }else if (document.getElementById(iframeName) ) {
<         frWindow = document.getElementById(iframeName).contentWindow;
<     }else {
<         return ;
<     }
<
<     fr = document.getElementById(iframeName);
<     if (frWindow && frWindow.document)
<         frDocument = frWindow.document;
<     else if (fr && fr.contentDocument)
<         frDocument = fr.contentDocument;
<
<     return frDocument;
< }
<
< function checkb() {
<     g_delivery = 'none';    g_delivery = 'none';
<     if (dsIsActiveXEnabled()){
<         g_delivery = 'activex';
<     }else if (dsIsJavaEnabled()) {
<         g_delivery = 'java';
<     }    document.deliveryType = g_delivery;
<     return g_delivery;
< }
<
< // Redirect to CGI to download the Setup Client .exe
< function redirectToSetupCGI() {
<     var href = window.location.href;
<     var redirectURL = "/dana-na/setup/download.cgi?r=" + escape(href);
<     if (dsIsMac()) {
<         redirectURL = redirectURL + "&platform=Macintosh";
<     }
<     window.location = redirectURL;
< }
<
< function loadControlFrame()
< {
<     try {
<         loadIframe ('controlframe', window.location);
<     } catch (e) {
<         failComponents();
<         setTimeout("gowelcome();", 0);
<     }
< }
<
< function setCheckBrowserCookie () {
<     if (g_checkbCookieSet == false) {
<         document.cookie = "DSCheckBrowser=" + escape(g_delivery) +
"; path=/;secure";
<         g_checkbCookieSet = true;
<     }
< }
<
< function submitBrowserInfo() {
<     setCheckBrowserCookie ();
<     if (g_delivery == 'none') {
<         setErrorMessage ('Your browser does not support either
ActiveX controls or Java applets. Please contact your
administrator.');
<         failComponents ();
<         gowelcome();
<     } else {
<         loadControlFrame();
<     }
< }
<
< function startOnLoad()
< {
<  var c = checkb();
<  if ((c == 'none') && (dsIsVista() || dsIsWinXP() || dsIsMac())) {
<      failComponents ();
<      setTimeout("redirectToSetupCGI();", 7000);
<      return;
<  }
<     setTimeout ("submitBrowserInfo();", 2000);}
< </script>
<
<
<
< <script>
< <!--
< if (window.top != self) {
< top.location = location;
< }
< //--></script>
< </head>
<
< <body bgcolor="#FFFFFF" color="#000000" link="#3366CC"
vlink="#CC6699" alink="#3366CC" leftmargin="0" topmargin="0"
rightmargin="0" marginwidth="0" marginheight="0"
onload="startOnLoad()" >
<
<
< <table id="table_PleaseWait_1" border="0" width="100%"
cellspacing="0" cellpadding="3">
<         <tr>
<             <td bgcolor="E3E3E3"><img border="0"
src="/dana-na/auth/welcome.cgi?p=logo" alt="Logo"></td>
<        <td bgcolor="E3E3E3" align="right">&nbsp;</td>
<
<         </tr>
< </table>
< <table id="table_PleaseWait_2" cellpadding="0" cellspacing="0"
border="0" width="100%">
<         <tr>
<                 <td bgcolor="#000000" colspan="2"><img border="0"
src="/dana-na/imgs/space.gif" width="1" height="1"></td>
<         </tr>
< </table>
< <blockquote>
<         <table id="table_PleaseWait_3" border="0" cellpadding="2"
cellspacing="0">
< <tr><td nowrap ><font face="verdana,sans-serif" size="3"><b>Loading
Components...</b></font></td></tr>
< <tr><td nowrap ><font face="verdana,sans-serif" size="2">Please
wait. This may take several minutes.</font></td></tr>
<         </table>
<
< <table id="table_PleaseWait_4" cellpadding="4" cellspacing="0"
border="0" width="100%"> <tr>
< <td><img src="/dana-na/imgs/space.gif" width="30" height="1"></td>
< <td><span style="font-weight:bold; color:#808080; font-size:135%;"
id="hcbulb">&#0149;</span></td>
< <td width="100%"><span><div id="hc">Host Checker</div></span></td>
< </tr> <tr>
< <td> </td>
< <td> </td>
< <tr>
<         <table id="table_PleaseWait_5" border="0" cellpadding="2"
cellspacing="0">
< <tr><td nowrap ><font face="verdana,sans-serif" size="2">
<         <div id="continue">If an error prevents a component from
loading properly, you can <a href="javascript:void(0)"
onclick="javascript:gowelcome();return false;">click here</a> to
continue. Not all functionality may be available.
</div></font></td></tr>
<         </table>
< </tr>
< <tr>
< <td><img src="/dana-na/imgs/space.gif" width="30" height="1"></td>
< </tr>
< <tr>
< <td><img src="/dana-na/imgs/space.gif" width="30" height="1"></td>
< </tr>
<         <table id="table_PleaseWait_6" border="0" cellpadding="2"
cellspacing="0">
< <tr><td nowrap ><font face="verdana,sans-serif" size="2"><div
id="endstatus"></div></font></td></tr>
<         </table>
< </table>
< </blockquote>
< <OBJECT classid="clsid:F27237D7-93C8-44C2-AC6E-D6057B9A918F"
<  id=NeoterisSetup
codebase="\dana-cached\sc\JuniperSetupClient.cab#version=2,1,1,1"
< width=0 height=0 >
< </object><p align="left"><iframe id="controlframe"
name="controlframe" src="/dana-na/html/blank.html" width="2"
height="2" frameborder="0" scrolling="NO"></iframe></p>
<
< </body>
<
< </html>
Failed to find or parse web form in login page
Failed to obtain WebVPN cookie
Dustin L Hartung


On Tue, Jan 24, 2017 at 3:17 PM, Daniel Lenski <dlenski at gmail.com> wrote:
> On Tue, Jan 24, 2017 at 12:16 PM, Dustin Hartung
> <dustin.hartung at gmail.com> wrote:
>> Thank you for the response and tip.  I tried as you said - running it
>> with --dump using a user agent and without as there appears to be
>> different requirements/rules depending on the device type- the results
>> are below:
>
> Yes, this is pretty typical for Juniper. It appears that your VPN uses
> authentication forms that are larded up with JavaScript.
>
> You might also want to try --useragent ncsvc, which spoofs the UA of
> Juniper's official desktop client, and often results in a simpler and
> easier-to-parse HTML page.
>
> For an example of where this works: I use a VPN which authenticates
> with "SecureMatrix". With a mobile/desktop UA, it generates a pattern
> of images using Java or ActiveX applets and I have to enter the
> numbers shown in the applet? but with "ncsvc" it generates a simple
> pure-text page that makes it easy to scrape and login automatically
> with a Python script (https://github.com/dlenski/smxlogin).
>
> Also, keep in mind that you can do "manual" external authentication as
> described in the OpenConnect manual:
> http://www.infradead.org/openconnect/juniper.html
>
> Basically, just login via the web interface, then show the DSID cookie
> in your browser, and run:
>
>     $ openconnect --juniper -C "DSID=foobar12345" vpn.example.com
>
> -Dan


From dlenski at gmail.com  Tue Jan 24 16:29:46 2017
From: dlenski at gmail.com (Daniel Lenski)
Date: Tue, 24 Jan 2017 16:29:46 -0800
Subject: Failed to obtain WebVPN cookie
In-Reply-To: <CAMedPwWvaXOnOW6w=QgZ9PCxtyWAd2sGMxhf+WAs32GVpCaTMw@mail.gmail.com>
References: <CAMedPwXovK3YKi8x4S6J6FzMNnJOrDZ-Nh_L1LKOL1JqZ45eGQ@mail.gmail.com>
 <CAOw_LSHhQJTs_gdyuL40OS6UteaGHnE2gcFnoRc88jxf=LOVSA@mail.gmail.com>
 <CAMedPwUv7Pt0okGH2WdykJNavD-ABBnQJ0taZfrrNs64Oc5mdw@mail.gmail.com>
 <CAOw_LSGZwiQRV=FB2mhnV5gDHPCbzW7FbFcQUYscOLk-DuO6TA@mail.gmail.com>
 <CAMedPwWvaXOnOW6w=QgZ9PCxtyWAd2sGMxhf+WAs32GVpCaTMw@mail.gmail.com>
Message-ID: <CAOw_LSGa0mPYKQnQb0o1C4LT=gySDvMBC90PBY6hx7Lehr=vgA@mail.gmail.com>

On Tue, Jan 24, 2017 at 1:53 PM, Dustin Hartung
<dustin.hartung at gmail.com> wrote:
> the ncsvc switch didnt seem to do anything different....  In terms of
> the DSID cookie - i am exactly sure how to generate it.  We use the
> junos client on Macs/iPhones and the Network Connect client in
> windows.

When you're using Network Connect client on Windows, this is exactly
what it's sending: "User-Agent: ncsvc"

> We dont necessarily login from a browser.  If i do try to
> hit that page from a web browser it shows loading components *Host
> Checker"  and if i view the cookies i see the following:
>
> opentoken
> DSSigninURL
> DSSIGNIN
> DSPREAUTH
> DSLAUNCHURL
> DSHCSTARTED

The good news is that you have confirmed that your VPN does indeed use
the Host Checker, so you'll want to continue your debugging down that
route.

The bad news is that your VPN actually uses the Host Checker :-(

I don't have access to a Juniper VPN with Host Checker currently, so I
can't help you with this one any further.

-Dan


From dustin.hartung at gmail.com  Tue Jan 24 16:51:23 2017
From: dustin.hartung at gmail.com (Dustin Hartung)
Date: Tue, 24 Jan 2017 18:51:23 -0600
Subject: Failed to obtain WebVPN cookie
In-Reply-To: <CAOw_LSGa0mPYKQnQb0o1C4LT=gySDvMBC90PBY6hx7Lehr=vgA@mail.gmail.com>
References: <CAMedPwXovK3YKi8x4S6J6FzMNnJOrDZ-Nh_L1LKOL1JqZ45eGQ@mail.gmail.com>
 <CAOw_LSHhQJTs_gdyuL40OS6UteaGHnE2gcFnoRc88jxf=LOVSA@mail.gmail.com>
 <CAMedPwUv7Pt0okGH2WdykJNavD-ABBnQJ0taZfrrNs64Oc5mdw@mail.gmail.com>
 <CAOw_LSGZwiQRV=FB2mhnV5gDHPCbzW7FbFcQUYscOLk-DuO6TA@mail.gmail.com>
 <CAMedPwWvaXOnOW6w=QgZ9PCxtyWAd2sGMxhf+WAs32GVpCaTMw@mail.gmail.com>
 <CAOw_LSGa0mPYKQnQb0o1C4LT=gySDvMBC90PBY6hx7Lehr=vgA@mail.gmail.com>
Message-ID: <CAMedPwWt9FN5Z6C4=uCFXnVxiBVchDN-hwRN+EvS-r_TLXWHxg@mail.gmail.com>

Would you need access to login - or just the actual link?
Dustin L Hartung


On Tue, Jan 24, 2017 at 6:29 PM, Daniel Lenski <dlenski at gmail.com> wrote:
> On Tue, Jan 24, 2017 at 1:53 PM, Dustin Hartung
> <dustin.hartung at gmail.com> wrote:
>> the ncsvc switch didnt seem to do anything different....  In terms of
>> the DSID cookie - i am exactly sure how to generate it.  We use the
>> junos client on Macs/iPhones and the Network Connect client in
>> windows.
>
> When you're using Network Connect client on Windows, this is exactly
> what it's sending: "User-Agent: ncsvc"
>
>> We dont necessarily login from a browser.  If i do try to
>> hit that page from a web browser it shows loading components *Host
>> Checker"  and if i view the cookies i see the following:
>>
>> opentoken
>> DSSigninURL
>> DSSIGNIN
>> DSPREAUTH
>> DSLAUNCHURL
>> DSHCSTARTED
>
> The good news is that you have confirmed that your VPN does indeed use
> the Host Checker, so you'll want to continue your debugging down that
> route.
>
> The bad news is that your VPN actually uses the Host Checker :-(
>
> I don't have access to a Juniper VPN with Host Checker currently, so I
> can't help you with this one any further.
>
> -Dan


From nmav at gnutls.org  Wed Jan 25 07:40:54 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 25 Jan 2017 16:40:54 +0100
Subject: Radius: Acct-Session-Id missing from Interim-Updates?
In-Reply-To: <83193460-F84A-4403-A592-30D40CE1EE83@icloud.com>
References: <83193460-F84A-4403-A592-30D40CE1EE83@icloud.com>
Message-ID: <CAJU7zaJ86kFV1og2HyNMPN56+SCLp3o2SR7+PVNH27-LaoxJBw@mail.gmail.com>

On Tue, Jan 24, 2017 at 5:39 PM, Niels Peen <nielspeen at icloud.com> wrote:
> Hi Nikos,
>
> I noticed ocserv 0.11.6 includes an Acct-Session-Id with the Start packet, but not with the Interim-Update packets. Is this the correct behaviour? If so, is it possible to (optionally) add the Acct-Session-Id to all accounting packets?
>
> (If I understand RFC2866 correctly the Acct-Session-Id is required for all accounting requests.)

As far as I understand it is the same code sending both messages
(append_acct_standard() in acct/radius.c). Could you add some
debugging information to check why PW_ACCT_SESSION_ID is not sent on
subsequent messages?

regards,
Nikos


From nielspeen at icloud.com  Wed Jan 25 10:45:24 2017
From: nielspeen at icloud.com (Niels Peen)
Date: Wed, 25 Jan 2017 19:45:24 +0100
Subject: Radius: Acct-Session-Id missing from Interim-Updates?
In-Reply-To: <CAJU7zaJ86kFV1og2HyNMPN56+SCLp3o2SR7+PVNH27-LaoxJBw@mail.gmail.com>
References: <83193460-F84A-4403-A592-30D40CE1EE83@icloud.com>
 <CAJU7zaJ86kFV1og2HyNMPN56+SCLp3o2SR7+PVNH27-LaoxJBw@mail.gmail.com>
Message-ID: <F6C32F54-C41F-4FAE-91B9-2630B1441A05@icloud.com>

> As far as I understand it is the same code sending both messages
> (append_acct_standard() in acct/radius.c). Could you add some
> debugging information to check why PW_ACCT_SESSION_ID is not sent on
> subsequent messages?

I made a configuration error which caused this problem to occur. My dictionary was missing the Framed-IPv6-Address attribute.

Problem resolved.

Thanks,
Niels

From hiharsh at gmail.com  Thu Jan 26 13:52:06 2017
From: hiharsh at gmail.com (harsh P)
Date: Thu, 26 Jan 2017 16:52:06 -0500
Subject: Once Again connecting as non root user.
Message-ID: <CA+mubHqewdEtX2uA_Coga1=jKLvojVrSZUsgDU9v3_98iRN3ZA@mail.gmail.com>

As I described earlier, I would like to connect to VPN server from C++
code as a non-root user.
I would also like to avoid interactive  question response "yes ,
username, passowrd" as prompted by the openconnect. I have been not
successful yet to achieve this.

Any help would be appreciated.
I have the following main questions.
1) Is it feasible to use script with embedded user name, passowrd and
VPN server address in the script and with quite option to launch
openConnect?
Any example script?  and how do I inform openconnect to use the script?

2) I am not getting past the error associated with the nonroot user
mode connection here is the complete information.

I followed the documentation at

http://www.infradead.org/openconnect/nonroot.html


sudo ip tuntap add vpn0 mode tun user ABC
[sudo] password for smartcart:
user at smartcart-VirtualBox:~/BASE/build/bin$ whoami
smartcart
user at smartcart-VirtualBox:~/BASE/build/bin$ openconnect -b X.X.X.X
POST https://X.X.X.X/
Attempting to connect to server X.X.X.X
SSL negotiation with X.X.X.X
Server certificate verify failed: signer not found

Certificate from VPN server "4.35.251.210" failed verification.
Reason: signer not found
Enter 'yes' to accept, 'no' to abort; anything else to view: yes
Connected to HTTPS on X.X.X.X
Got HTTP response: HTTP/1.0 302 Object Moved
GET https://X.X.X.X/
Attempting to connect to server X.X.X.X443
SSL negotiation with X.X.X.X
Server certificate verify failed: signer not found
Connected to HTTPS on X.X.X.X
Got HTTP response: HTTP/1.0 302 Object Moved
GET https://4X.X.X.X/+webvpn+/index.html
SSL negotiation with X.X.X.X
Server certificate verify failed: signer not found
Connected to HTTPS on X.X.X.X
Please enter your username and password.
GROUP: [sslvpnclient]:sslvpnclient

Please enter your username and password.
Username:dABC
Password:
POST https://4.35.251.210/+webvpn+/index.html
Got CONNECT response: HTTP/1.1 200 OK
CSTP connected. DPD 30, Keepalive 20
Failed to bind local tun device (TUNSETIFF): Operation not permitted
To configure local networking, openconnect must be running as root
See http://www.infradead.org/openconnect/nonroot.html for more information
Set up tun device failed

user at smartcart-VirtualBox:~/BASE/build/bin$ sudo ip tuntap add vpn0
mode tun user ABC
ioctl(TUNSETIFF): Device or resource busy


-- 
Thanks & Regards
Harsh


From mtmiller at debian.org  Thu Jan 26 16:53:30 2017
From: mtmiller at debian.org (Mike Miller)
Date: Thu, 26 Jan 2017 16:53:30 -0800
Subject: Once Again connecting as non root user.
In-Reply-To: <CA+mubHqewdEtX2uA_Coga1=jKLvojVrSZUsgDU9v3_98iRN3ZA@mail.gmail.com>
References: <CA+mubHqewdEtX2uA_Coga1=jKLvojVrSZUsgDU9v3_98iRN3ZA@mail.gmail.com>
Message-ID: <20170127005330.2gbn7pkxyadu7ktl@galago.mtmxr.com>

On Thu, Jan 26, 2017 at 16:52:06 -0500, harsh P wrote:
> 1) Is it feasible to use script with embedded user name, passowrd and
> VPN server address in the script and with quite option to launch
> openConnect?
> Any example script?  and how do I inform openconnect to use the script?

I think so, if I'm reading you correctly. Something like this?

  echo "$password" | openconnect --user="$username" --password-on-stdin "$gateway"

> 2) I am not getting past the error associated with the nonroot user
> mode connection here is the complete information.
> 
> I followed the documentation at
> 
> http://www.infradead.org/openconnect/nonroot.html
> 
> 
> sudo ip tuntap add vpn0 mode tun user ABC

Hmm, is "ABC" standing in for something else here? I think you want
"user smartcart" here. It should be the name of the local user that is
going to be running openconnect.

> [sudo] password for smartcart:
> user at smartcart-VirtualBox:~/BASE/build/bin$ whoami
> smartcart
> user at smartcart-VirtualBox:~/BASE/build/bin$ openconnect -b X.X.X.X

I think you are missing the --interface=IFNAME (or -i) option here. It
is mentioned on the page you referenced. If you created a tun device
named "vpn0" as you showed above, then you should add "--interface=vpn0"
to your openconnect command.

(I haven't tested any of this, just following the docs and the code.)

-- 
mike


From dab at dab.la  Sun Jan 29 14:51:14 2017
From: dab at dab.la (dab at dab.la)
Date: Sun, 29 Jan 2017 16:51:14 -0600
Subject: Trouble connecting to Junos Pulse VPN
Message-ID: <a471f6784b999696f9ec7a50cdeaac45@dab.la>

First, thank you for making a client for this! My company's IT dept 
seems unwilling to download the Junos Linux client, and Junos won't give 
me access to it.

This VPN server uses 2 factor authentication with an SMS message sent to 
my phone. There are two problems, the first being relatively 
insignificant, but also possibly related.

OS: Debian Jessie with all packages upgraded to testing.
Openconnect: 7.08-1
network-manager-openconnect-gnome: 1.2.4-1
XFCE4

Problem 1 / Feature Request: When I connect, I am first prompted for 
username and password. There is a checkbox to remember the password. I 
fill the fields and check the box and submit. It comes back with the 2nd 
factor auth field "frmDefender". The "Save Passwords" field is still 
there. In the Junos mac client, if i try this, it tries to save the 2nd 
factor which is different on each login. That causes all kinds of 
problems with the client. It would be great if the "Save Passwords" 
field were separate or clearer as to which fields it was saving.

Problem 2: After the 2nd factor, the process fails. I have attached all 
the logs below, but it looks like this is the problem: "Unknown form ID 
'frm'"

Thank you in advance for any help! :D


GET https://vpn.domain.com/
Attempting to connect to server ip.ip.ip.ip:443
Connected to ip.ip.ip.ip:443
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 302 Found
Location: https://vpn.domain.com/dana-na/auth/url_default/welcome.cgi
Content-Type: text/html; charset=utf-8
Set-Cookie: DSSIGNIN=url_default; path=/dana-na/; expires=Thu, 
31-Dec-2037 00:00:00 GMT; secure
Set-Cookie: DSIVS=; path=/; expires=Thu, 01 Jan 1970 22:00:00 GMT; 
secure
Set-Cookie: DSSignInURL=/; path=/; secure
Connection: close
Content-Length: 0
HTTP body length:  (0)
GET https://vpn.domain.com/dana-na/auth/url_default/welcome.cgi
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Sun, 29 Jan 2017 22:24:00 GMT
x-frame-options: SAMEORIGIN
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
POST https://vpn.domain.com/dana-na/auth/url_default/login.cgi
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 302 Moved
location: 
https://vpn.domain.com/dana-na/auth/url_default/welcome.cgi?p=defender&id=state_effed4707128a27cd2ebaa4cb90c7f75
Content-Type: text/html; charset=utf-8
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
GET 
https://vpn.domain.com/dana-na/auth/url_default/welcome.cgi?p=defender&id=state_effed4707128a27cd2ebaa4cb90c7f75
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Sun, 29 Jan 2017 22:24:32 GMT
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
X-Frame-Options: SAMEORIGIN
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
Ignoring unknown form submit item 'secidactionCancel'
POST https://vpn.domain.com/dana-na/auth/url_default/login.cgi
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 302 Moved
location: 
https://vpn.domain.com/dana-na/auth/remediate.cgi?step=rolecheck&stateId=state_effed4707128a27cd2ebaa4cb90c7f75&realmId=85&rolesremaining=0&realmsremaining=1
Content-Type: text/html; charset=utf-8
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
GET 
https://vpn.domain.com/dana-na/auth/remediate.cgi?step=rolecheck&stateId=state_effed4707128a27cd2ebaa4cb90c7f75&realmId=85&rolesremaining=0&realmsremaining=1
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 302 Moved
location: 
/dana-na/auth/login.cgi?key=state_effed4707128a27cd2ebaa4cb90c7f75&RoleSkipRemediate=1
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
GET 
https://vpn.domain.com/dana-na/auth/login.cgi?key=state_effed4707128a27cd2ebaa4cb90c7f75&RoleSkipRemediate=1
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 302 Moved
location: 
https://vpn.domain.com/dana-na/auth/url_default/welcome.cgi?p=no-roles
Content-Type: text/html; charset=utf-8
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
GET 
https://vpn.domain.com/dana-na/auth/url_default/welcome.cgi?p=no-roles
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 302 Moved
Date: Sun, 29 Jan 2017 22:25:01 GMT
location: 
/dana-na/auth/remediate.cgi?step=installfail&signinId=url_default&realmsremaining=0&p=no-roles
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
GET 
https://vpn.domain.com/dana-na/auth/remediate.cgi?step=installfail&signinId=url_default&realmsremaining=0&p=no-roles
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
X-Frame-Options: SAMEORIGIN
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
Unknown form ID 'frm'
GET https://vpn.domain.com/
Attempting to connect to server ip.ip.ip.ip:443
Connected to ip.ip.ip.ip:443
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 302 Found
Location: https://vpn.domain.com/dana-na/auth/url_default/welcome.cgi
Content-Type: text/html; charset=utf-8
Set-Cookie: DSSIGNIN=url_default; path=/dana-na/; expires=Thu, 
31-Dec-2037 00:00:00 GMT; secure
Set-Cookie: DSIVS=; path=/; expires=Thu, 01 Jan 1970 22:00:00 GMT; 
secure
Set-Cookie: DSSignInURL=/; path=/; secure
Connection: close
Content-Length: 0
HTTP body length:  (0)
GET https://vpn.domain.com/dana-na/auth/url_default/welcome.cgi
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Sun, 29 Jan 2017 22:25:12 GMT
x-frame-options: SAMEORIGIN
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
POST https://vpn.domain.com/dana-na/auth/url_default/login.cgi
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 302 Moved
location: 
https://vpn.domain.com/dana-na/auth/url_default/welcome.cgi?p=defender&id=state_b81b6495ed86ce92a8765ff1a2b1a612
Content-Type: text/html; charset=utf-8
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
GET 
https://vpn.domain.com/dana-na/auth/url_default/welcome.cgi?p=defender&id=state_b81b6495ed86ce92a8765ff1a2b1a612
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Sun, 29 Jan 2017 22:25:57 GMT
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
X-Frame-Options: SAMEORIGIN
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
Ignoring unknown form submit item 'secidactionCancel'
POST https://vpn.domain.com/dana-na/auth/url_default/login.cgi
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 302 Moved
location: 
https://vpn.domain.com/dana-na/auth/remediate.cgi?step=rolecheck&stateId=state_b81b6495ed86ce92a8765ff1a2b1a612&realmId=85&rolesremaining=0&realmsremaining=1
Content-Type: text/html; charset=utf-8
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
GET 
https://vpn.domain.com/dana-na/auth/remediate.cgi?step=rolecheck&stateId=state_b81b6495ed86ce92a8765ff1a2b1a612&realmId=85&rolesremaining=0&realmsremaining=1
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 302 Moved
location: 
/dana-na/auth/login.cgi?key=state_b81b6495ed86ce92a8765ff1a2b1a612&RoleSkipRemediate=1
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
GET 
https://vpn.domain.com/dana-na/auth/login.cgi?key=state_b81b6495ed86ce92a8765ff1a2b1a612&RoleSkipRemediate=1
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 302 Moved
location: 
https://vpn.domain.com/dana-na/auth/url_default/welcome.cgi?p=no-roles
Content-Type: text/html; charset=utf-8
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
GET 
https://vpn.domain.com/dana-na/auth/url_default/welcome.cgi?p=no-roles
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 302 Moved
Date: Sun, 29 Jan 2017 22:26:31 GMT
location: 
/dana-na/auth/remediate.cgi?step=installfail&signinId=url_default&realmsremaining=0&p=no-roles
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
GET 
https://vpn.domain.com/dana-na/auth/remediate.cgi?step=installfail&signinId=url_default&realmsremaining=0&p=no-roles
SSL negotiation with vpn.domain.com
Connected to HTTPS on vpn.domain.com
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
X-Frame-Options: SAMEORIGIN
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
Unknown form ID 'frm'


From dab at dab.la  Mon Jan 30 21:12:27 2017
From: dab at dab.la (dab at dab.la)
Date: Mon, 30 Jan 2017 23:12:27 -0600
Subject: Trouble connecting to Junos Pulse VPN
In-Reply-To: <a471f6784b999696f9ec7a50cdeaac45@dab.la>
References: <a471f6784b999696f9ec7a50cdeaac45@dab.la>
Message-ID: <de7f76914d34dbb545101ba4205050b5@dab.la>

It appears that this might have something to do with hostchecker.

Ultimately I get this:

Unknown form ID 'frm'
Dumping unknown HTML form:
<form id="frm_142" name="frm" action="remediate.cgi">

     <input id="action_31" type="hidden" name="action" value="">

     <input id="signinId_2" type="hidden" name="signinId" 
value="url_default">
     <input id="realmId_10" type="hidden" name="realmId" value="">
     <input id="executedStep_2" type="hidden" name="executedStep" 
value="installfail">
     <input id="stateId_8" type="hidden" name="stateId" value="">
     <input id="p_16" type="hidden" name="p" value="no-roles">

     <input id="showContinue_2" type="hidden" name="showContinue" 
value="0">
     <input id="showRemedOption_2" type="hidden" name="showRemedOption" 
value="0">

     <input id="hostcheckTS_2" type="hidden" name="hostcheckTS" value="">
     <input id="totalseconds_2" type="hidden" name="totalseconds" 
value="">

     <input id="executedAction_2" type="hidden" name="executedAction" 
value="">
</form>Failed to obtain WebVPN cookie

But this happens after I successfully log in and then there are several 
redirects. Also on the same page, I notice the following outside of the 
form:

<                 <td width="100%">
<                     <b>Your computer's security is 
unsatisfactory</b><br><br>
<                     <span class="cssSmall">Host Checker is not 
supported. Please contact your Administrator.</span>
<                 </td>



