Re: --cafile enabling system-trust nevertheless?
On Sat, Sep 7, 2024 at 2:19 AM David Woodhouse wrote: > > - What you're seeing here is the tunnel/data phase, running in the > > `openconnect` process (as a privileged user). > > No, NetworkManager runs openconnect as an *unprivileged* user. Not > actually "nobody" but its own "NM-openconnect" version of nobody. > > All it can do is open the one /dev/net/tun device which was created for > it by NetworkManager, and shovel packets back and forth. And send the > IP configuration back to NetworkManager via D-Bus to be set up. > > Running unprivileged in the tunnel phase is a key part of the > openconnect security model (and it's different to the Cisco crap, which > runs as root for a lot of things where it really shouldn't). Thanks, I hadn't realized that NM refines the required privileges of the openconnect binary down to one tun device plus D-Bus. > If you run openconnect from the *command* line, then yes it'll need to > invoke its vpnc-script with CAP_NET_ADMIN in order to configure the > networking. And CAP_SYS_ADMIN to let it write /etc/resolv.conf. But in > that model you can still do the *authentication* as your normal user, > as shown at https://www.infradead.org/openconnect/nonroot.html Right, that's the unprivileged-for-authentication piece that I was describing. > (And even then, strictly openconnect itself doesn't need privs; I've > never experimented much with 'openconnect -s "sudo vpnc-script", and > I'm not entirely sure there's much point without a lot of focus on > hardening vpnc-script itself to be a safe entry point.) I definitely played around with this quite a lot while working on https://github.com/dlenski/vpn-slice and then actually used it at $OLDOLDJOB for managing a small herd of simultaneous VPN connections. If you want the vpnc-script to be able to configure routing and DNS, it still needs root/CAP_*_ADMIN privileges. ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: --cafile enabling system-trust nevertheless?
On Sun, Sep 8, 2024 at 1:10 PM Martin Pauly wrote:
> On 07.09.24 07:14, Daniel Lenski wrote:
> >> Ooh, interesting. Reading between the lines a bit here… "leaving a CA
> >> setting blank" in WiFi enterprise authentication (802.1x) resulted in
> >> "don't validate the RADIUS server's certificate at all." So your
> >> clients then connected to forged/spoofed APs+RADIUS servers!?
>
> Exactly. Especially Android devices used to do this in vast numbers (~30%),
> as of 2020 (had been even worse since at least 2008). During a change of
> root cert (preadating the one mentioned above) we were really troubled
> about our eduroam users, so many devices to set up/renew. But it went so
> smoothly
> that we got suspicious. We launched an investigation (including a real world
> attack)
> which confirmed our apprehensions. During the course of this investigation,
> the option "Do not validate" suddenly started to disappear from the Androids.
> Turns out, others had also understood the issue to its full extent and put it
> on their list.
> WPA3-R2 prohibits the presence of that option (thanks here to Stefan Winter).
> Now I compare this to
Interesting. eduroam is the only 802.1x-using wifi network that I've
ever configured *for myself*.
But as an end user of eduroam, why should I actually be concerned if
I've connected to a "counterfeit" eduroam access point, as long as it
gives me real internet connectivity? The eduroam network doesn't
really give me access to any particular internal network. There isn't
really a trust boundary with eduroam. And if my device is sending any
non-e2ee'd-and-cert-validated traffic, it's already susceptible to
eavesdropping and MITM attacks by middleboxes on *any* network.
Am I missing something in this case?
I'd contrast this with a corporate or institutional wifi network
("BigCorp-Internal") where connecting to the internal network might
imply some actual trust boundary between inside and outside, and so a
forged AP would be of concern both to admins and to end users.
Daniel
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: --cafile enabling system-trust nevertheless?
On Mon, Sep 2, 2024 at 4:56 AM Martin Pauly wrote: > > Am 01.09.24 um 06:32 schrieb Daniel Lenski: > > Actually, the original question came from the GUI side, i.e. Network Manager. > A colleague of mine recently stumbled on our outdated documentation > recommending to set CA Certificate to the old T-Telesec cert. > He figured out he could connect to my current server (presenting the new > USERTrust cert) > no matter what CA element he added of left blank. > When testing, I naïvely assumed the "CA Certificate" would directly translate > to --cafile. > Add the old manpage, and you have my perfect misinterpretation. > > But a closer look reveals different details yet again, identical on both the > old Ubuntu and a current Debian. > No matter what I specify in "CA Certificate", ps always shows this Command > line being run in reality: > nm-open+ 39622 0.1 0.0 62992 12672 ?S11:17 0:00 > /usr/sbin/openconnect --servercert > pin-sha256:BjvO2hCuK4pVXupG9fmwOAbdsaTc/LORPdn6Al2LRD0= --syslog > --cookie-on-stdin --script > /usr/lib/NetworkManager/nm-openconnect-service-openconnect-helper --interface > vpn0 137.248.1.225:443/+webvpn+/index.html > > The pin-sha256:BjvO2hCuK4pVXupG9fmwOAbdsaTc/LORPdn6Al2LRD0= > matches the current USERTrust cert [[[ Just before I hit send, seeing that Wade Cline has already replied and explained most of this 👇, but perhaps this additional detail is useful. ]]] OpenConnect is explicitly designed to separate the authentication and tunnel/data "phases" of a VPN connection, so that they can run in separate processes. - What you're seeing here is the tunnel/data phase, running in the `openconnect` process (as a privileged user). - The authentication phase has *already run* as part of the GUI process (as an unprivileged user). What happens in the authentication phase is that you fill out the authentication forms and communicate with the server, which sends an authentication token (it's simply an HTTP cookie in the case of the AnyConnect protocol). NM records the fingerprint of the server's TLS certificate during the authentication phase, as well as the authentication token/cookie. In order to establish the tunnel/data phase connection, NetworkManager starts a new (privileged) `openconnect` process, feeding it the authentication token via `--cookie-on-stdin`, and requiring the server certificate to exactly match the one seen during the authentication phase via `--servercert pin-sha256:$HASH`. Most of the documentation on the 2-phase authentication lives in the code and devs' heads, but there are some references in the manual (https://www.infradead.org/openconnect/manual.html#:~:text=The%20connection%20happens,tcp.html. and https://www.infradead.org/openconnect/manual.html#opt-authenticate) and in a 2020 presentation that I gave (https://www.dropbox.com/scl/fi/2ideixgr6sa7jcw49glbu/How-VPNs-Work-Daniel-Lenski-at-DAMA-PDX-September-2020.pdf). > so Network Manager always seems to call openconnect > as if I had enabled --no-system-trust, but trusted the current USERtrust cert > explicitly -- is this correct? > > If so, is this intended behavior? As described above, the actual certificate *validation* happens during the authentication phase, and you're only seeing the *tunnel* phase here. So this *is* the intended behavior, but an incomplete picture of what has actually happened in terms of cert validation. > And: Is there a NM/GUI setting equivalent to --no-system-trust? My knowledge of the NM GUI is both incomplete and out-of-date, but not as far as I know. > (Really sorry to bother, we've turned to a "Once bitten, twice shy" mindset > after we learned that leaving a CA setting blank has proved disastrous > in the context of WiFi supplicants. With openconnect, we're obviously > apart from that kind of problems by a long shot.) Ooh, interesting. Reading between the lines a bit here… "leaving a CA setting blank" in WiFi enterprise authentication (802.1x) resulted in "don't validate the RADIUS server's certificate at all." So your clients then connected to forged/spoofed APs+RADIUS servers!? You'll probably be reassured to know that openconnect (the CLI application) has not had an option to disable certificate validation altogether in many year 😅. https://gitlab.com/openconnect/openconnect/commit/6c95e85f154f2ee24b8914ab6c0ffe555152ca7f Daniel ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Question about package build
On Sun, Sep 1, 2024 at 4:10 PM Daniel Lenski wrote: > > On Sun, Sep 1, 2024 at 1:46 PM Moorko wrote: > > > > Thanks for your detailed response, Daniel. > > > > I now realize that I clearly missed the big picture here as I'm relatively > > new to this domain. > > No worries! Looks like you're tackling a tricky problem and asking the > right questions :-) > > > > I'm not sure what "flexible" means specifically. > > > > I'm implementing a TLS handshake fragmentation feature for OpenConnect so > > that it can better resist internet censorship in Iran (and potentially in > > other places as well). > > Ah. We have a tag for Iran-censorship-related issues, definitely > peruse these if you haven't already: > https://gitlab.com/openconnect/openconnect/-/issues/?label_name%5B%5D=Damet%20Garm You might also be interested in https://gitlab.com/openconnect/openconnect/-/merge_requests/297, where I added the `--sni` option to aid in https://en.wikipedia.org/wiki/Domain_fronting (another anti-censorship technique). That one also required some careful fine-tuning to handle the change in expectations of the server's TLS certificate when built with either OpenSSL or GnuTLS. ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Question about package build
On Sun, Sep 1, 2024 at 1:46 PM Moorko wrote: > > Thanks for your detailed response, Daniel. > > I now realize that I clearly missed the big picture here as I'm relatively > new to this domain. No worries! Looks like you're tackling a tricky problem and asking the right questions :-) > > I'm not sure what "flexible" means specifically. > > I'm implementing a TLS handshake fragmentation feature for OpenConnect so > that it can better resist internet censorship in Iran (and potentially in > other places as well). Ah. We have a tag for Iran-censorship-related issues, definitely peruse these if you haven't already: https://gitlab.com/openconnect/openconnect/-/issues/?label_name%5B%5D=Damet%20Garm Here's a recent and very timely Twitter thread that touches on using packet fragmentation at various layers to defeat censorship: https://twitter.com/endermanch/status/1829648801612906916 As described in this thread, injecting extra fragmentation is AT BEST a stopgap solution, exploiting a lack of (or bugginess in) stateful session tracking, and nation-level censors WILL eventually prevent it from working. > This "fragmentation" can occur at two layers: > > 1. The TLS handshake record layer > > 2. The TCP layer > > I found an API in OpenSSL that allows for modifying the TLS ClientHello > packet for this purpose: > https://docs.openssl.org/master/man3/SSL_CTX_set_split_send_fragment/ > > However, I couldn't find a similar API in GnuTLS. > > Performing TCP layer segmentation for ClientHello is possible in both OpenSSL > and GnuTLS as it is possible in both of them to inject your own transport > layer send() function. > > It is possible to implement TLS record fragmentation in GnuTLS, but it would > require manually handling the entire process within the custom send() > function. This approach feels a bit hacky and might compromise code > consistency. What do you think? Would the team consider merging something > like this? It's probably not a feature that would be used by most users > (since I presume most users don't have censorship problems), but it could > significantly help those trying to evade censorship. > > It was only after I implemented the fragmentation feature that I realized > Linux distributions wouldn't include this change because by default they're > using GnuTLS and I only implemented this for OpenSSL. 😅 Sounds like you've already implemented it for OpenSSL? Does using this API actually allow you to successfully bypass the Divar-e-Bozorg and establish a TLS handshake with a TLS-based VPN server? 😅 And if so, can you share the code/diff? (Perhaps privately if you prefer.) If this technique does actually work for circumventing censorship, I think we could make a very good case for adding a similar capability to GnuTLS and I'd be happy to help with it :-) > > What's the source for this "better performance" claim > > It's probably not valid. I haven't run any benchmarks myself, so I apologize > for making an unverified claim. I read it here: > https://subscription.packtpub.com/book/security/9781800560345/2/ch02lvl1sec06/comparing-openssl-with-gnutls Let's leave this part aside for now since it's probably not the most important problem to solve. Daniel ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Question about package build
On Sun, Sep 1, 2024 at 8:19 AM Moorko wrote: > I noticed that the OpenConnect package available in Linux distributions > like Ubuntu and Fedora is built with GnuTLS rather than OpenSSL. > Is there a specific reason for this? Many such reasons, from my point of view… 1. Historically, OpenSSL didn't support the pre-release/non-standardized version of DTLS used by Cisco in a consistent or stable way (even though Cisco's own DTLS implementation was clearly built using a specific ancient version of OpenSSL 😵💫). OpenConnect's BDFL David Woodhouse had to cajole them into intentionally supporting it, and then to add tests for it so they'd stop breaking it over and over in new releases. 2. By contrast, GnuTLS developers have taken a personal interest in OpenConnect. In fact, the collaboration and curiosity that resulted from implementing Cisco's pre-release version of DTLS in GnuTLS largely inspired the development of ocserv 😃,. See https://nikmav.blogspot.com/2013/11/inside-ssl-vpn-protocol.html 3. The GnuTLS API is well-designed, well-documented, and has fewer archaeological layers of legacy cruft. 4. The ocserv server is built with GnuTLS, and sometimes it's helpful to share code and knowledge between the client and server components. > As far as I know, OpenSSL is more flexible I'm not sure what "flexible" means specifically. OpenSSL is a very long-running project and contains several layers of legacy APIs that sometimes interact in strange views. From my point of view as a longtime OpenConnect developer, most of the code that deals with TLS/DTLS/ESP directly is *simpler and more maintainable* in its GnuTLS versions than in its OpenSSL versions. Compare https://gitlab.com/openconnect/openconnect/-/blob/master/gnutls-dtls.c vs. https://gitlab.com/openconnect/openconnect/-/blob/master/openssl-dtls.c for instance. Having worked with OpenSSL quite a bit in other commercial and FLOSS projects, I'd say that the "flexibility" of OpenSSL is more often a liability than an asset. 🤷🏻♂️ > and offers better performance. What's the source for this "better performance" claim and how does it impact OpenConnect specifically? Daniel ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: --cafile enabling system-trust nevertheless?
On Fri, Aug 30, 2024, 1:42 PM Cline, Wade wrote: > > On Fri, Aug 30, 2024 at 07:14:07PM +0200, Martin Pauly wrote: > > Hi all, > > > > we have encountered what we think might be a sloppy check of the server > > cert by the openconnect client. > > AFAIU, --cafile allows the user to pin the CA that has signed off the > > server cert to a certain root cert. > > This is supposed to enable a much stricter server identity check than one > > gets with the > > default behavior of trusting any known system cert (e.g. any of the root > > certs in /etc/ssl/certs). > > … > > Isn't '--cafile' for *additional* CAs and hence the above command includes > both the system certs and the T-Telesec cert (possibly redundantly)? > Wouldn't you want to explicitly specify the T-Telesec cert with '--cafile' > and '--no-system-trust' for the above test? Thanks Wade, this is entirely correct. The additive effect of `--cafile` is intentional and is prominently mentioned in the OpenConnect manual page for both options, and has been for several years. Not sure how we can possibly be more explicit than what I added in https://gitlab.com/openconnect/openconnect/-/commit/ceab1765db11c15a18a0c605812dbc11afd63e8b, but happy for any additional suggestions. 😬 Thanks, Daniel ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: ESP Connection Refused Question
On Thu, Aug 1, 2024 at 9:58 AM Benjamin Cardon wrote: > > Here is the handshake [of the connection when ESP works] still using GPopen > in case it's helpful. There is no apparent difference between these logs other than the fact that the ESP-over-UDP packets get through in one and not the other. Whatever is going wrong here, it likely has to do with middleboxes in your network environment blocking UDP traffic to the VPN server's port 4501, and has nothing to do with OpenConnect in particular. ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: ESP Connection Refused Question
On Wed, Jul 31, 2024 at 8:58 AM Benjamin Cardon wrote: > Attached is the handshake. Everything up to line 72 is collecting the > auth cookie from Okta. Yes, it appears from this log that there's simply no UDP connectivity between the client and the server. The ESP-over-UDP tunnel can't be connected, and so OpenConnect gives up and uses the TLS tunnel instead. Jul 31 09:24:00 xps15 plasmashell[3351696]: 2024-07-31 09:24:00.977 INFO [3351696] [GPClient::onVPNLogAvailable@518] Failed to connect ESP tunnel; using HTTPS instead. UDP connectivity can be broken in all kinds of idiosyncratic ways that are often specific to your network environment. The most important thing to try, in terms of NARROWING DOWN the possible breakages, would be to rerun this from the network environment *where ESP does work* and *compare the logs*. In particular, does anything change in the /ssl-vpn/getconfig.esp response, besides the randomized IPSEC security parameters and perhaps the IP address assigned to the client? And to make debugging easier, use https://github.com/dlenski/gp-saml-gui + the OpenConnect command-line interface (instead of the GUI-fied wrapper of https://github.com/yuezk/GlobalProtect-openconnect). ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: ESP Connection Refused Question
On Tue, Jul 30, 2024 at 11:47 AM Benjamin Cardon wrote: > > Hi, my company has a GlobalProtect VPN and I've been successfully > using it using GPopen and openconnect for years. What is GPopen? > A few months ago, they changed something in our network or VPN that is > causing the VPN to fail to connect via ESP when I'm in our office, though it > works perfectly fine outside the office network. I have tried to figure out > what exactly is preventing ESP from starting up and the only thing I can > really see in the logs that is different between in the office versus out of > the office is this log > > Jul 30 11:06:33 xps15 plasmashell[3116179]: 2024-07-30 11:06:33.467 > INFO [3116179] [GPClient::onVPNLogAvailable@518] ESP receive error: > Connection refused > > My question is, what does this log line imply and where is the connection > being refused from? Find and provide additional context, and then we'll both have a better idea of what's going on. As Karl Pinc wrote, run the OpenConnect command-line client with `-vvv --dump-http-traffic` and share the logs from that, particularly log messages about ESP configuration. > Is it just UDP packets to the gateway address? Prior to this, it does do a > handshake using Okta to sign in which works just fine so it's transferring > the ESP packets explicitly that seems to be the problem. To me, this suggests > a network configuration/firewall issue but I need more info to tell our > networking team what to investigate. It is *likely* that some kind of middlebox is preventing UDP packets from getting through in the non-working network environment, but there are other possibilities as well. ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Debugging UDP ESP failure
On Sat, Jul 27, 2024 at 2:03 PM Karl O. Pinc wrote: > > > I put together a fix for this in > > https://gitlab.com/openconnect/openconnect/-/commits/handle_GP_ESP_magic_address_corner_case > > > > Can you please build and test that? I don't have a real GP VPN that I > > can test it on anymore, unfortunately. > > Works for me. The output includes: > > ESP session established with server > ESP tunnel connected; exiting HTTPS mainloop. > Configured as READACTEDIPV4NUMBER, with SSL disconnected and ESP established > > And I see the expected UDP traffic go through the firewall. Thanks! Excellent, thanks. I was able to add some semi-automated tests thanks to your detailed report here, and I've created an MR to fix it in the next release at https://gitlab.com/openconnect/openconnect/-/merge_requests/565 ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Debugging UDP ESP failure
On Thu, Jul 25, 2024 at 4:59 PM Karl O. Pinc wrote:
> Thanks for the reply. Here's the info you asked for.
> It looks like the proprietary client sets up a UDP VPN
> and openconnect does not.
Thanks. From your detailed log I have an idea of what's going on:
> POST https://vpnhost.example.com/ssl-vpn/getconfig.esp
> > POST /ssl-vpn/getconfig.esp HTTP/1.1
> > Host: vpnhost.example.com
> > User-Agent: PAN GlobalProtect
> > Cookie: PHPSESSID=0d908f7158db4981ddb0a77a0333afcb;
> > CLIENTOS=V2luZG93cw%3D%3D
> > X-Pad: 0
> > Content-Type: application/x-www-form-urlencoded
> > Content-Length: 327
> >
> > client-type=1&protocol-version=p1&internal=no&app-version=5.2.13-48&ipv6-support=no&clientos=Windows&os-version=win&hmac-algo=sha1%2cmd5%2csha256&enc-algo=aes-128-cbc%2caes-256-cbc&authcookie=1ae1b6537c0b886eabff1091c6433944&portal=gp-staff-faculty-ext-getway-N&user=REDACTEDUSER%40example.com&domain=%28empty_domain%29&computer=slate
> Got HTTP response: HTTP/1.1 200 OK
> Date: Thu, 25 Jul 2024 21:47:42 GMT
> Content-Type: application/xml; charset=UTF-8
> Content-Length: 2352
> Connection: keep-alive
> Pragma: no-cache
> Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
> Expires: Thu, 19 Nov 1981 08:52:00 GMT
> X-FRAME-OPTIONS: DENY
> Strict-Transport-Security: max-age=31536000;
> X-XSS-Protection: 1; mode=block
> X-Content-Type-Options: nosniff
> Content-Security-Policy: default-src 'self'; script-src 'self'
> 'unsafe-inline'; img-src * data:; style-src 'self' 'unsafe-inline';
> HTTP body length: (2352)
> <
> <
> < yes
> < /ssl-tunnel-connect.sslvpn
> < gp-staff-faculty-ext-getway-N
> < redactedu...@example.com
> < no
> < 86400
> < 10800
> < 10800
> < 1000
> < 1000
> < REDACTEDIPV4ADDRESS7
> < REDACTEDIPV6ADDRESS7
> < no
> < REDACTEDIPV4ADDRESS0
> < 255.255.255.255
> < yes
> <
> < REDACTEDIPV4ADDRESS1
> < REDACTEDIPV4ADDRESS2
> < REDACTEDIPV4ADDRESS3
> < REDACTEDIPV4ADDRESS4
> < REDACTEDIPV6ADDRESS1
> < REDACTEDIPV6ADDRESS2
> <
> <
> < REDACTEDIPV4ADDRESS1
> < REDACTEDIPV4ADDRESS2
> < REDACTEDIPV4ADDRESS3
> < REDACTEDIPV4ADDRESS4
> <
> <
> <
> <
> < example.com
> <
> < REDACTEDIPV4ADDRESS0
> < 0
> <
> no
> <
> < 0.0.0.0/0
> < REDACTEDIPV4ADDRESS1/32
> < REDACTEDIPV4ADDRESS2/32
> < REDACTEDIPV4ADDRESS3/32
> < REDACTEDIPV4ADDRESS4/32
> <
> <
> < ::/0
> <
> <
> <
> <
> <
> <
> < 4501
> < esp-tunnel
> < aes-128-cbc
> < sha1
> < 0x5F672823
> < 0x9FCCE331
> <
> < 160
> <
> 4822b9bc1129308917434b8779fc1b5b2b93a491
> <
> <
> < 128
> < 12e4597fc6b3a161e67be1cb27d80534
> <
> <
> < 160
> <
> fffcfca75dad43a42b56babb9c317ff1cb1020e9
> <
> <
> < 128
> < 80fc6f79af6635c3253b1e5bbf48a068
> <
> <
> <
> Tunnel timeout (rekey interval) is 180 minutes.
> Idle timeout is 180 minutes.
> Did not receive ESP keys and matching gateway in GlobalProtect config; tunnel
> will be TLS only.
OpenConnect is reporting "did not receive ESP keys and matching
gateway in GlobalProtect config". The "matching gateway" part is key.
Your VPN is indeed showing a previously unanticipated case, where the
VPN sends an IPv6 magic ping address
("REDACTEDIPV6ADDRESS7") but it
*doesn't* send an IPv6 client address (there is no "").
In that case, we need to use the IPv4 magic ping address even though
we NORMALLY prefer the IPv6 magic ping address, because that one is
required if we want to be able to use both IPv6 and IPv4.
I put together a fix for this in
https://gitlab.com/openconnect/openconnect/-/commits/handle
Re: Debugging UDP ESP failure
On Wed, Jul 24, 2024 at 3:02 PM Karl O. Pinc wrote: > > No matter the -vvv, I get no real information as to why. "No real information" is not actionable. If you run a recent version of OpenConnect with `-vvv --dump-http-traffic --protocol=gp`, you should ALWAYS get AT LEAST ONE log line that specifically mentions ESP, even if it is to simply tell you why OpenConnect thinks ESP is unavailable. (Like https://gitlab.com/openconnect/openconnect/-/blob/64f0c03d660f1d17834f7ff7ce9d0151704bb32f/gpst.c#L621) Please share those. > Although I did notice some ICMP IPv6 packets. Which would have to > go through the VPN or else won't be passed by my firewall. > It's unclear if these have to do with ESP or not. Further, > FYI, they seem to be sent even when using --disable-ipv6. When OpenConnect sends ICMP packets to initiate/activate/enable the GlobalProtect ESP tunnel, those packets are themselves encapsulated via ESP and sent over the tunnel. https://gitlab.com/openconnect/openconnect/-/blob/64f0c03d660f1d17834f7ff7ce9d0151704bb32f/gpst.c#L1565 So if you aren't capturing these ICMP IPv6 packets *on the tunnel interface itself*, then they have nothing to do with OpenConnect/GlobalProtect/ESP. > I can use the VPN without ESP, and maybe the issue is > server-side anyway, but I thought I'd ask to see if there > was anything easy to try. What I always recommend is that you test with a PAN GlobalProtect proprietary client running on the same local network as OpenConnect. - If the proprietary client can't establish an ESP tunnel, then it's unsurprising if OpenConnect also can't establish an ESP tunnel. Quite likely either something is broken in the VPN server's configuration, or some middlebox isn't passing ESP-over-UDP traffic. - If the proprietary client *can* establish an ESP tunnel, but OpenConnect can't, then we certainly want to know more… but over the past ~6 years we think we've eliminated almost all of those cases. https://gitlab.com/openconnect/openconnect/-/commits/64f0c03d660f1d17834f7ff7ce9d0151704bb32f/gpst.c?search=ESP ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Bug Report - OpenConnect VPN Connection Issue on Ubuntu 24
On Wed, Jun 19, 2024 at 7:05 PM Lee <309820...@qq.com> wrote: > Dear author, > I hope this email finds you well. I am writing to report a bug that I have > encountered while using the OpenConnect software on my Ubuntu 24 system. > When attempting to connect to a VPN using OpenConnect, I am prompted to enter > my password as expected. However, after entering the password, the > application requests a real-time verification code that is sent to my email > address. Unfortunately, the terminal does not provide me with an input field > for this code, and the connection fails without any further explanation. > I understand that this issue may be due to a limitation in the OpenConnect > software or the underlying VPN infrastructure. However, I was wondering if > there is any possibility of this bug being fixed in future updates or if > there are any workarounds that I can use in the meantime to successfully > connect to the VPN. > Thank you for your attention to this matter. I look forward to hearing from > you soon. > Best regards, > rugnag.li > > > The output of the terminal is as follows： > > POST https://vpn2fa.hku.hk/ > Connected to 147.8.240.41:443 > SSL negotiation with vpn2fa.hku.hk > Connected to HTTPS on vpn2fa.hku.hk with ciphersuite > (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-128-GCM) > Got HTTP response: HTTP/1.1 404 Not Found > Unexpected 404 result from server > GET https://vpn2fa.hku.hk/ > Connected to 147.8.240.42:443 > SSL negotiation with vpn2fa.hku.hk > Connected to HTTPS on vpn2fa.hku.hk with ciphersuite > (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-128-GCM) > Got HTTP response: HTTP/1.0 302 Object Moved > GET https://vpn2fa.hku.hk/+webvpn+/index.html > SSL negotiation with vpn2fa.hku.hk > Connected to HTTPS on vpn2fa.hku.hk with ciphersuite > (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-128-GCM) > Please enter your username and password. > Password: > POST https://vpn2fa.hku.hk/+webvpn+/index.html > -Please enter your token code > POST https://vpn2fa.hku.hk/+webvpn+/login/challenge.html > Login failed. > Please enter your username and password. > Password: This is some variant of https://gitlab.com/openconnect/openconnect/-/issues/665, with the additional complication that your server doesn't like clients which identify themselves as *Linux* systems. 🤷🏻♂️ Add '--os=win' and/or '--useragent=AnyConnect' to your command line to workaround this. Daniel ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: MITM to a cisco client
On Thu, May 9, 2024 at 1:08 AM David Woodhouse wrote: > On Wed, 2024-05-08 at 17:59 -0600, Oscar Velazquez wrote: > > I have a hunch: it is to change server-cert-hash, but I do not know > > what the correct values could be or if this is a valid approach. > > Any help would be appreciated. > > > > Probably the sha1 fingerprint of the (real) server's SSL certificate. Yes indeed. > In http://david.woodhou.se/proxy.go there's support for changing such a > hash to the hash of the cert you're using for the proxy itself. I would recommend using *mitmproxy* for this purpose, because I contributed support for making this much easier there back in 2017. 😄 In https://github.com/mitmproxy/mitmproxy/commit/391f28f78cf9f4ee2f82c69c7f5ce370b69b77cd, I added support for extracting the MITM proxy's certificate in a script. You can see an example of this in use in my jun_ssl_log.py script (https://gist.github.com/dlenski/33bfa3a8691686d02ddaf7a51843a89a#file-jun_ssl_log-py-L42-L44) which I used a bunch for MITM'ing Juniper clients. In addition to trying to *rewrite* the tag, you might also want to try simply *removing* it from the returned XML. That's what I did in a similar context in the gp_ssl_log.py (https://gitlab.com/dlenski/pangp-hacks/-/blob/master/gp_ssl_log.py?ref_type=heads#L63-68) for MITM'ing GlobalProtect clients, and it worked fine. The proprietary clients tend to have fail-open/permissive-by-default fallbacks when their anti-MITM information is removed or disabled. More details at https://www.infradead.org/openconnect/mitm.html#antimitm. ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Re:
On Sat, Apr 20, 2024 at 12:35 PM Peter Tulpen wrote: > Hello,we want to use openconnect to connect to our company network and having > like 2 modes: > - always have a connection to our management server based on a client > certificate, so the management server can scan him: basic connection > - when a user needs resources, let him login via 2FA : user connection > > This could be done with 2 tunnels, but is there a more elegant way, like > always having the basic connection switch to the "user connection" on demand > (and falling back to the basic connection when the "user connection" is gone) What exactly is wrong with 2 tunnels? This would almost certainly be the most reliable, straightforward, and composable way to implement what you want. Without explicit support for this "mode-switching" IN THE VPN SERVER, the graceful transition and fallback between the 2 tunnels would likely be VERY difficult to implement. Within the OpenConnect client, we have enough trouble ensuring graceful fallback between TLS- and ESP/DTLS-based tunnels of a single ALREADY-AUTHENTICATED logical client session. We regularly discover new quirks and inconsistencies within the supported VPN protocols that make this a challenge. On Mon, Apr 22, 2024 at 6:31 AM Peter Tulpen wrote: > the server is a palo alto prisma I wrote [almost all of] the support for the Palo Alto / GlobalProtect protocol in the OpenConnect *client* (https://www.infradead.org/openconnect/globalprotect.html). However, I know ABSOLUTELY NOTHING about how GlobalProtect *servers* work, or how they're configured… other than what I can infer from the numerous bugs, security holes, and inconsistencies that I've encountered over the years. 😬 > To avoid the issue of having a connection in a connection I hope split > tunneling and clever routing rules should be sufficient Yes, I think you're on the right track here. Setup 2 separate tunnels, and ensure that the routes they require don't overlap or interfere with each other. Daniel ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: SSL huawei AR150 Series Enterprise Routers
On Mon, Apr 15, 2024 at 10:35 AM Alfredo Tomasini wrote: > Note: the router is not a cisco but huawei AR150, in spite most likely > they use the same protocol, maybe! You probably should've led with that 😬. There is absolutely no reason to think a *Huawei* server would work with the AnyConnect protocol, or any of the other protocols currently supported by OpenConnect. > In case you have time and interest, this is the server 58.246.39.91:8899 > (better not to post this, I guess) According to the what-vpn tool (https://github.com/dlenski/what-vpn) that I maintain, this server is indeed speaking the Huawei SSL VPN protocol, which is a protocol that OpenConnect does not yet support. See https://gitlab.com/openconnect/openconnect/-/issues/603 for a discussion of this protocol. Would be happy to work with someone who uses this VPN protocol to add support to OpenConnect. ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: SSL huawei AR150 Series Enterprise Routers
On Fri, Apr 12, 2024 at 4:29 PM Alfredo Tomasini wrote: > I am trying to get a vpn connection to our pattern in China What does this mean? (Maybe your meant PARTNER in China… maybe not?) > by using > openconnect Specifically, you're using OpenConnect v9.01 according to your logs. Released just about 2 years ago, and bundled with many Linux distributions. > this is error > > XML response has no "auth" node > > Failed to complete authentication > > never get to login and password > > The server is not configure to use certificates > > I am not an expert on this subject, but by looking at the header of the > dump > it seems the connection happen, but something is not interpreted > properly. It appears very likely that this is https://gitlab.com/openconnect/openconnect/-/issues/665. Try adding `--user-agent="AnyConnect"` to the command-line. If that makes it work, then yes it is this frustrating issue caused by Cisco changing their servers’ authentication process in a backwards-incompatible way… not just incompatible with all previous versions of OpenConnect, but also with very old versions of their *own* software. This is fixed in the master branch as of https://gitlab.com/openconnect/openconnect/-/merge_requests/497, but not yet in any released version of OpenConnect. ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Howto ignore obtained routes from server?
On Wed, Apr 3, 2024 at 2:49 AM Markus Robert Kessler wrote: > > When using networkmanager for invoking openconnect, there is an option > "Ignore automatically obtained routes". > This is essential because some obtained routes conflict with local addresses. > > Unfortunately, we cannot find the relevant commandline option to set this > in openconnect directly. https://github.com/dlenski/vpn-slice is designed specifically for use cases like this one. > We have a newsgroup discussion ongoing, but no one knows. vpn-slice is prominently linked to in one of the first hits if you Google "openconnect ignore routes" or "openconnect split tunnel." ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: [PATCH] Fix connection stats rekey times
On Tue, Feb 27, 2024 at 7:20 PM Cline, Wade wrote: > On Tue, Feb 27, 2024 at 03:37:47PM -0800, Daniel Lenski wrote: > Sorry about that; I added the sign-off in one environment but forgot to > sync the two before sending the patch! Thank you, now merged and with a changelog entry. https://gitlab.com/openconnect/openconnect/-/commit/d2025f9d49637065aaa15f506b022c45765cf6b7 ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: TCP Sessions get disconnected at 6, 9 hours
On Tue, Feb 27, 2024 at 3:58 PM Larry Ploetz wrote: > > On 2024-02-25 11:03, Larry Ploetz wrote: > >> Are the users of the official PAN GP clients keeping SSH sessions open > >> for 6+ hours like you are? > > > > > > Yes, I believe so. I'll verify. > > Yes, ssh as well as other TCP connections are staying open for more than > 6 hours. > > > > I'll get back with more information. > > > No indication of any packets in openconnect's stderr, only routing > changes being made (add host/add net), and those are on startup - the > timestamps on the redirected stdout/stderr files are when openconnect > was started + 11 seconds. You say you're collecting logs with maximum debugging verbosity (`--vvv --dump-http-traffic --timestamp`)… but you see *nothing at all* in the logs around 6 hours? 🤷🏻♂️ That makes no sense. With either the ESP tunnel (https://gitlab.com/openconnect/openconnect/blob/master/esp.c#L217-432) or with the TLS tunnel (https://gitlab.com/openconnect/openconnect/blob/master/gpst.c#L1224-1364) you should be getting a log message with every single packet sent or received over the tunnel, including keepalive/DPD packets. Your initial command line included `--syslog`, so the logs are certainly *not going to stderr* after the connection is established. https://www.infradead.org/openconnect/manual.html#opt-syslog Are you sure you're looking at the right logs, in the right place? ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Suddenly, a new connection error
On Sat, Jan 20, 2024 at 4:41 PM Dave Brosius wrote:
> However today, when i try to connect, i get
>
> Connected as 10.69.12.166 + 2606:b400:600:c063::11c/64, using SSL,
> with DTLS in progress
> Established DTLS connection (using GnuTLS). Ciphersuite
> (DTLS1.2)-(ECDHE-RSA)-(AES-256-GCM).
> Detected MTU of 1182 bytes (was 1280)
> RTNETLINK answers: Invalid argument
> Error: ipv4: Invalid values in header for route get request.
> Usage: ip route { list | flush } SELECTOR
>ip route save SELECTOR
>
>
>
> So I tried openconnect without vpn-slice and the problem still remains
Your tethered connection is resulting in a tunnel MTU that's smaller
than what is required for IPv6 (which requires a minimum of 1280
bytes). This is a fundamental requirement of the IPv6 protocol,
enforced by the OS (Linux in this case) and various middleboxes.
I can identify the immediate source of this error:
1. When you use vpn-slice (https://github.com/dlenski/vpn-slice), that
error is coming from:
https://github.com/dlenski/vpn-slice/blob/master/vpn_slice/__main__.py#L175
2. When you use the standard vpnc-script
(https://gitlab.com/openconnect/vpnc-scripts/-/blob/master/vpnc-script),
that error is coming from
https://gitlab.com/openconnect/vpnc-scripts/blob/master/vpnc-script#L245
… but I'm a little bit uncertain about exactly what's leading up to it.
> The only thing on my end that changed was my phone (which i'm
> hotspoting thru) got an upgrade.
I *suspect* that your new phone enables IPv6 for the tethered
interface, while the old one didn't. But I'm not 100% sure. In the
initial output of `openconnect MY.SERVER.COM`, on the "Connected to X"
line, is X an IPv4 address or an IPv6 address?
Could you add `-vvv` to both the OpenConnect arguments *and* the
`vpn-slice` arguments, e.g. `openconnect -vvv MY.SERVER.COM --script
"/path/to/vpn-slice -vvv"`?
> Anyone have any suggestions on what i can do to fix or diagnose this?
As you already discovered, `--disable-ipv6` will at least prevent you
from encountering this error, but we'd really like to have a better
error message and/or succeed in enabling IPv6.
> Am using v8.05-1
This is a very old release, from 2019.
We've made a number of MTU detection improvements since then, so it
would be good to know if you encounter the same error when testing
against the latest release, v9.12, or building from source
(https://gitlab.com/openconnect/openconnect) against the master
branch.
Thanks,
Daniel
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: [PATCH] Fix connection stats rekey times
On Tue, Feb 27, 2024 at 9:04 AM Daniel Lenski wrote:
>
> On Mon, Feb 26, 2024 at 6:50 PM Cline, Wade wrote:
> >
> > ---
> > main.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/main.c b/main.c
> > index 65be6a2f..ef426dd6 100644
> > --- a/main.c
> > +++ b/main.c
> > @@ -1565,14 +1565,14 @@ static void print_connection_stats(void *_vpninfo,
> > const struct oc_stats *stats)
> > vpninfo->proto->udp_protocol ? : "UDP",
> > openconnect_get_dtls_cipher(vpninfo));
> > if (vpninfo->ssl_times.last_rekey && vpninfo->ssl_times.rekey)
> > vpn_progress(vpninfo, PRG_INFO, _("Next SSL rekey in %ld
> > seconds\n"),
> > -(long)(time(NULL) -
> > vpninfo->ssl_times.last_rekey + vpninfo->ssl_times.rekey));
> > +(long)(vpninfo->ssl_times.last_rekey +
> > vpninfo->ssl_times.rekey - time(NULL)));
> > if (vpninfo->dtls_times.last_rekey && vpninfo->dtls_times.rekey)
> > vpn_progress(vpninfo, PRG_INFO, _("Next %s rekey in %ld
> > seconds\n"),
> > vpninfo->proto->udp_protocol ? : "UDP",
> > -(long)(time(NULL) -
> > vpninfo->ssl_times.last_rekey + vpninfo->ssl_times.rekey));
> > +(long)(vpninfo->ssl_times.last_rekey +
> > vpninfo->ssl_times.rekey - time(NULL)));
> > if (vpninfo->trojan_interval && vpninfo->last_trojan)
> > vpn_progress(vpninfo, PRG_INFO, _("Next Trojan invocation
> > in %ld seconds\n"),
> > -(long)(time(NULL) - vpninfo->last_trojan +
> > vpninfo->trojan_interval));
> > +(long)(vpninfo->last_trojan +
> > vpninfo->trojan_interval - time(NULL)));
> >
> > /* XX: restore loglevel */
> > openconnect_set_loglevel(vpninfo, saved_loglevel);
>
> Thank you, good catch here. These have been calculated incorrectly
> ever since I added the SIGUSR1 handler to log connection stats in
> https://gitlab.com/openconnect/openconnect/-/commit/b156b581e894b03e7169827b9e293ca2f13e1366.
>
> And thanks Dimitri for creating
> https://gitlab.com/openconnect/openconnect/-/merge_requests/539 for
> this.
Hi Wade,
Could you please resend this patch with `Signed-off-by: NAME `
in the footer? (`git commit --signoff` will do this)
Our BDFL David reminded us in
https://gitlab.com/openconnect/openconnect/-/merge_requests/539#note_1791676817
that we need to get this from the original author of every patch. ☺
Thanks!
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: [PATCH] Fix connection stats rekey times
On Mon, Feb 26, 2024 at 6:50 PM Cline, Wade wrote:
>
> ---
> main.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/main.c b/main.c
> index 65be6a2f..ef426dd6 100644
> --- a/main.c
> +++ b/main.c
> @@ -1565,14 +1565,14 @@ static void print_connection_stats(void *_vpninfo,
> const struct oc_stats *stats)
> vpninfo->proto->udp_protocol ? : "UDP",
> openconnect_get_dtls_cipher(vpninfo));
> if (vpninfo->ssl_times.last_rekey && vpninfo->ssl_times.rekey)
> vpn_progress(vpninfo, PRG_INFO, _("Next SSL rekey in %ld
> seconds\n"),
> -(long)(time(NULL) -
> vpninfo->ssl_times.last_rekey + vpninfo->ssl_times.rekey));
> +(long)(vpninfo->ssl_times.last_rekey +
> vpninfo->ssl_times.rekey - time(NULL)));
> if (vpninfo->dtls_times.last_rekey && vpninfo->dtls_times.rekey)
> vpn_progress(vpninfo, PRG_INFO, _("Next %s rekey in %ld
> seconds\n"),
> vpninfo->proto->udp_protocol ? : "UDP",
> -(long)(time(NULL) -
> vpninfo->ssl_times.last_rekey + vpninfo->ssl_times.rekey));
> +(long)(vpninfo->ssl_times.last_rekey +
> vpninfo->ssl_times.rekey - time(NULL)));
> if (vpninfo->trojan_interval && vpninfo->last_trojan)
> vpn_progress(vpninfo, PRG_INFO, _("Next Trojan invocation in
> %ld seconds\n"),
> -(long)(time(NULL) - vpninfo->last_trojan +
> vpninfo->trojan_interval));
> +(long)(vpninfo->last_trojan +
> vpninfo->trojan_interval - time(NULL)));
>
> /* XX: restore loglevel */
> openconnect_set_loglevel(vpninfo, saved_loglevel);
Thank you, good catch here. These have been calculated incorrectly
ever since I added the SIGUSR1 handler to log connection stats in
https://gitlab.com/openconnect/openconnect/-/commit/b156b581e894b03e7169827b9e293ca2f13e1366.
And thanks Dimitri for creating
https://gitlab.com/openconnect/openconnect/-/merge_requests/539 for
this.
Daniel
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: TCP Sessions get disconnected at 6, 9 hours
First off, what is your `openconnect --version`? On Wed, Feb 21, 2024 at 11:24 AM Larry Ploetz wrote: > On 2024-02-20 00:25, Daniel Lenski wrote: > > Do you have some reason to think that this has anything to do with > > OpenConnect per se, as opposed to being a limitation of the servers > > you're connecting to… or perhaps of some other middlebox on the > > network? > > All network connections through openconnect disconnect 6 and 9 hours after > openconnect is started, regardless of when those network connections began > relative to openconnect starting. It looks like you're collecting very detailed logs from OpenConnect already (`--dump-http-traffic -vvv --timestamp`). What do those logs show around the 6- and 9-hour marks? Anything that's unusual? Anything *other than* the usual sent-a-packet/received-a-packet traffic? > The PAN VPN box is the only middlebox, and I suspect it a lot, but I haven't > heard of anyone here who are using Global Protect having this issue. Are the users of the official PAN GP clients keeping SSH sessions open for 6+ hours like you are? > > Other than your ssh sessions getting disconnected after 6/9 hours, > > does the VPN connection continue working normally after that? That is, > > can you continue opening *new* TCP connections over it? > > Yes, starting new connections works fine after the 6 hour disconnection. It > seems like there might be a minute or two while UDP connections to the DNSs > don't work, at the 6 and 9 hour marks. Okay, so there's nothing specific to SSH, or even TCP, here. Both TCP and UDP connections stop working around the 6/9 hour marks. ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: OpenConnect on a GP IPv6 Server
On Thu, Jan 11, 2024 at 6:25 PM wrote: > I am a physics student using openconnect on arch linux to connect to my > school's GlobalProtect server that uses both IPv6 and IPv4. So far, I > have not been able to connect using IPv6; IPv6 connection times out and > the vpn connects via IPv4. Let me know if you need any debug logs or > stdout Which version of OpenConnect, exactly? When you say "connect using IPv6", do you mean that you're trying to establish a connection between your client and the VPN gateway over the Internet using IPv6, or that you're trying to establish an IPv6 connection within the virtual network? Please provide more logs/details, in any case. You can email them to me individually if you prefer. I'm the author of pretty much all of the GP+IPv6 support… both the good parts and the remaining bugs 🥲 Daniel ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: TCP Sessions get disconnected at 6, 9 hours
On Wed, Jan 31, 2024 at 4:16 PM Larry Ploetz wrote: > I've noticed that all my ssh sessions, regardless of when they start > relative to the start of openconnect, get disconnected after openconnect > has been up 6 hours, and 9 hours (about - ± 5 minutes). I assume that > would happen with other long lasting TCP sessions (I've tried with socat > a few times and that seems to be the case). Do you have some reason to think that this has anything to do with OpenConnect per se, as opposed to being a limitation of the servers you're connecting to… or perhaps of some other middlebox on the network? > I'm using openconnect with GlobalProtect, which has a 12 hour time out. Other than your ssh sessions getting disconnected after 6/9 hours, does the VPN connection continue working normally after that? That is, can you continue opening *new* TCP connections over it? > Here's my command: > > openconnect --csd-wrapper openconnect/trojans/hipreport.sh --protocol=gp > --script=/etc/vpnc/vpnc-script --dump-http-traffic --timestamp -vvv > --user=larryp --syslog --passwd-on-stdin https://.com < > > outfile 2> errfile & echo $! > pidfiled Does it connect over TLS, or over ESP? Are there any messages about a requirement to periodically resubmit the HIP report? ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: [PATCH] Force final newline in xmlstarlet
On Sat, Feb 3, 2024 at 9:10 AM Jon DeVree wrote: > By default xmlstarlet does not include a final newline on the output. > Because POSIX says that all lines must end in a newline, this causes the > final line of output to be skipped by the 'while read ...' loop in bash. > Adding a '-n' after the '-v ...' causes xmlstarlet to include a final > newline at the end of its output. Thank you! Out of curiosity, on what platform(s) does this cause a problem? MacOS… *BSD…? I see this was already merged, thanks to Dimitri and Nikos (in https://gitlab.com/openconnect/openconnect/-/merge_requests/535). ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Openconnect and GP with IPv6
On Fri, Jan 19, 2024 at 4:33 AM Daniel Loxtermann wrote: > > Hey all! > > While trying to understand how to get IPv6 on our GlobalProtect Clients, > we found out about OpenConnect! > > You're asking for results about IPv6 with GP. As the author of the GP IPv6 support, thank you very much for this report. And also, my apologies for the belated response. I'm just now starting to dig myself out of a 4-month-deep hole resulting from taking a break from OpenConnect while I was on my honeymoon. > We're using IPv4 and IPv6 Split Tunneling with PanOS 11.0.3 and GP 6.1.2-83. > > So far, I can tell you this: Works great, if we're using Version 8.20. > Split tunneling with IPv6 stopped working with 9.00 and newer. I assume > that's related to > https://gitlab.com/openconnect/openconnect/-/merge_requests/367 Yes indeed. When I committed https://gitlab.com/openconnect/openconnect/-/commit/99ae55aec1408a2905df72394dab99cb6fb41aed, I didn't realize I was going to be causing a lot more problems than I had solved. 😅 > Due to the revert, the "include IPv6" is indeed recognized as "exclude > IPv6" (not v4 - that is included as it should) and instead of leaving > the default route alone, it's changed to the tunnel. Looks like > something is swapped here. > > I could fix this with adding "access-routes-v6" to line 532 in gpst.c: > https://gitlab.com/openconnect/openconnect/-/blob/master/gpst.c?ref_type=heads#L532 > (I've attached a patch, let me know if it's easier for you to create a > MR it GitLab, I'll create one then) Argh. That's an excellent catch. I've just pushed the fix up as https://gitlab.com/openconnect/openconnect/-/commit/64f0c03d660f1d17834f7ff7ce9d0151704bb32f, with your name on it. Thanks again for the detailed report, and will keep your offer in mind for the next time that we may need access to a "real" GlobalProtect server in order to fix something. Daniel ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: openconnect fails to connect to my school vpn
On Mon, Nov 6, 2023 at 9:08 AM Jang, WonSeok wrote: > My school uses duo mfa when logging in. > > Is there anyway to fix this?? I am currently using Arch linux. Your VPN requires SAML authentication, but OpenConnect generally can't handle SAML authentication on its own; an external web browser that supports JavaScript is required. For GlobalProtect, you need to use an external script to do the SAML authentication. Start by trying https://github.com/dlenski/gp-saml-gui ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Ubuntu 20.04 openconnect fails for GlobalProtect server
On Wed, Oct 25, 2023 at 3:45 PM O. William McClung wrote: > > I have openconnect v8.05-1, the latest for Ubuntu 20.04, and am trying > to connect to a GlobalProtect server which I know requires > gp-saml-gui. This is an extremely old version (from 2019). We've made a large number of improvements to GlobalProtect support in the intervening years. > POST > https://us-central-g-universi.gpo2ojjg5cnn.gw.gpcloudservice.com/ssl-vpn/login.esp > > … > > Failed to parse server response > Failed to obtain WebVPN cookie > > Thanks for any help you can provide. 1. Try building a more recent version of OpenConnect from source, and running that. 2. Run with `-vvv --dump-http-traffic`, look at the detailed server response which OpenConnect is failing to parse here, and share it with us (taking care to remove any passwords or secret cookies that appear in it). ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Fortinet / SAML support for Windows
On Thu, Sep 28, 2023 at 3:06 AM julio toribio wrote: > > I'm using Windows and trying to connect to a VPN(Fortinet) but by > default SAML is used to authenticate. When we hit connect in > Forticlient, a web browser is launched, we authenticate in i.e > Microsoft, then Forticlient is connected. > I saw the option --external-browser=BROWSER but openconnects complains > with "openconnect.exe: unknown option -- external-browser" > I tried replacing the "=" for an empty space (--external-browser > "C:\P...") but still the same result. > I'm I missing something? The short answer here is that OpenConnect does not yet have any support for SAML-based authentication using an external browser **with the Fortinet protocol**. See a related issue on GitLab: https://gitlab.com/openconnect/openconnect/-/issues/?state=all&label_name%5B%5D=protocol%3A%3AFortinet&label_name%5B%5D=External%20Auth%2FSAML%2FSSO As far as I know, none of the main OpenConnect developers have any access to a Fortinet VPN that uses SAML, so without a lot more details about *how* Fortinet does this SAML authentication (see https://gitlab.com/openconnect/openconnect/-/issues/356#note_912401634), it will not happen. As ever, more details on how it works (especially in the form of a merge request with working code :-)) would be welcome! ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Does the --background option exist for Windows?
On Mon, Sep 18, 2023 at 11:44 AM Daniel Lenski wrote: > On Sun, Sep 17, 2023 at 10:47 AM Paolo Ienne (严保罗) > wrote: > > Last but not least, you may want to note that the links to "master branch > > for > > 32-bit Windows or for 64-bit Windows" on > > > > https://www.infradead.org/openconnect/packages.html > > > > are broken. > > See the discussions on > https://gitlab.com/openconnect/openconnect/-/issues/498 and > https://gitlab.com/openconnect/openconnect/-/issues/621 > > It's very hard to convince GitLab's CI to persist the artifacts that > it builds for us, and the required URL format keeps changing. 🤕 Found an overlooked comment which likely goes a long way to explaining why the GitLab-CI artifact links are broken for us, again: https://gitlab.com/openconnect/openconnect/-/issues/286#note_1563911656 ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Does the --background option exist for Windows?
On Sun, Sep 17, 2023 at 10:47 AM Paolo Ienne (严保罗) wrote: > But I am writing to ask if it is correct that the Windows port of > OpenConnect does not offer the "--background" switch. It seems so (I > finally managed to access the latest build for Windows 10, thinking that > the slighter older one did not have it yet but newer might) but I find > this mentioned nowhere. This issue was opened on GitLab 1 week ago: https://gitlab.com/openconnect/openconnect/-/issues/655 There's also a merge request in progress attempting to add `--background` on Windows. This is difficult due to the fact that Windows uses a very different process model from POSIX-y systems. > Last but not least, you may want to note that the links to "master branch for > 32-bit Windows or for 64-bit Windows" on > > https://www.infradead.org/openconnect/packages.html > > are broken. See the discussions on https://gitlab.com/openconnect/openconnect/-/issues/498 and https://gitlab.com/openconnect/openconnect/-/issues/621 It's very hard to convince GitLab's CI to persist the artifacts that it builds for us, and the required URL format keeps changing. 🤕 > The "Fedora dwmw2/openconnect COPR" mentioned in the next > paragraph actually work--although it was a bit of an adventure to manage to > unpack the multiple layers of archives and compressions to finally get to the > single meaningful file inside the RPM. Yep, the COPR links *are* stored reliably, but it is indeed difficult to extract those files, and it'll definitely scare away some Windows users https://gitlab.com/openconnect/openconnect/-/issues/498#note_1128691313 Daniel ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Compilation problem with new gnutls
On Fri, Sep 1, 2023, 7:33 AM Mike Gilbert wrote: > > On Fri, Sep 1, 2023 at 4:47 AM Jarosław Siebert wrote: > > I updateted my Slackware machine and noticed that I can not compile > > openconnect with it. > > > > I use gnutls 3.8.1 > > > > when I try to compile openconnect 9.12 then it stops with error message: > > > > gnutls-dtls.c: In function 'start_dtls_handshake': > > gnutls-dtls.c:413:84: error: 'GNUTLS_NO_EXTENSIONS' undeclared (first > > use in this function); did you mean 'GNUTLS_EXT_NONE'? > >413 | err = gnutls_init(&dtls_ssl, > > GNUTLS_CLIENT|GNUTLS_DATAGRAM|GNUTLS_NONBLOCK|GNUTLS_NO_EXTENSIONS); > > | ^~~~ > > | GNUTLS_EXT_NONE > > gnutls-dtls.c:413:84: note: each undeclared identifier is reported only > > once for each function it appears in > > This was reported on gitlab 2 weeks ago. There are solutions available there. > > https://gitlab.com/openconnect/openconnect/-/issues/650 Yes indeed. I fixed this in the master branch, as of https://gitlab.com/openconnect/openconnect/-/commit/7512698217c4104aade7a2df669a20de68f3bb8c As I noted in the commit message, the lack of a backwards-compatible constant name (GNUTLS_NO_EXTENSIONS) appears to have been an inadvertent omission in GnuTLS 3.8.1, and should be fixed in the next release of GnuTLS due to a subsequent commit. ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: [EXT] Re: Unable to connect to GlobalProtect VPN
On Thu, Aug 17, 2023 at 11:04 AM Anthony Becker wrote: > Hi Daniel – > > Here is the openconnect version output: > > sshuser@oakvpn:~$ openconnect --version > OpenConnect version v8.20-1 > Using GnuTLS 3.7.3. Features present: TPMv2, PKCS#11, RSA software token, > HOTP software token, TOTP software token, Yubikey OATH, System keys, DTLS, ESP > Supported protocols: anyconnect (default), nc, gp, pulse, f5, fortinet, array > Default vpnc-script (override with --script): > /usr/share/vpnc-scripts/vpnc-script > > Neither “--clientos=Windows” nor “--usergroup=gateway:prelogin-cookie” worked > for me – I received the same error messages as before. Got it. Subsequent to the v8.20 release, we've made several small improvements to the GlobalProtect authentication-handling code. In particular, https://gitlab.com/openconnect/openconnect/-/commit/51586b29. 14:15 $ git log --decorate=no --oneline v8.20..v9.12 auth-globalprotect.c https://gitlab.com/openconnect/openconnect/-/commit/bf4338c6 Ignore blank labels sent in GlobalProtect prelogin https://gitlab.com/openconnect/openconnect/-/commit/c0d2daea Save GlobalProtect version reported by portal and parrot it back as client version https://gitlab.com/openconnect/openconnect/-/commit/27284f83 Prevent crash on unexpected response for GlobalProtect portal prelogin XML https://gitlab.com/openconnect/openconnect/-/commit/ce214b87 Expand comment about potentially-useful information in GP portal configuration https://gitlab.com/openconnect/openconnect/-/commit/9164e21e Clearer error message when GlobalProtect portal configuration contains no gateways at all https://gitlab.com/openconnect/openconnect/-/commit/51586b29 GP: add 'internal=no' flag to the login and configuration requests https://gitlab.com/openconnect/openconnect/-/commit/07386df8 No embedded URLs in translatable strings https://gitlab.com/openconnect/openconnect/-/commit/c58464a8 Declare C string constants using array syntax https://gitlab.com/openconnect/openconnect/-/commit/ff13a983 GP SAML: support legacy workflow https://gitlab.com/openconnect/openconnect/-/commit/3d0a3247 GP SAML: handle redirect case https://gitlab.com/openconnect/openconnect/-/commit/a287bc00 GP SAML: fix some memory handling https://gitlab.com/openconnect/openconnect/-/commit/c4c813ec start adding GP SSO support There's no guarantee that any of this will make a difference for your issue (as I said before, I haven't seen that exactly error message), but I would still recommend building and testing OpenConnect v9.12. Please let us know if you get same/different results with v9.12. Daniel ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Unable to connect to GlobalProtect VPN
On Mon, Aug 14, 2023 at 8:31 AM Anthony Becker wrote: > > > I am unable to connect to a GlobalProtect VPN. I start with the command: > > eval $( ./.local/bin/gp-saml-gui grizzvpn.oakland.edu --allow-insecure-crypto > ) > > A web form requests my username and password and sends me a Duo push. The > login succeeds and gives me a cookie to use when connecting. I then enter > the command: > > echo $MYCOOKIE | sudo openconnect --protocol=gp --user=$MYUSERNAME > --os=linux-64 --usergroup=portal:prelogin-cookie --passwd-on-stdin > grizzvpn.oakland.edu Please show output of `openconnect --version`. > > The login fails with: > > POST > https://grizzvpn.oakland.edu/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux > Attempting to connect to server 141.210.72.2:443 > Connected to 141.210.72.2:443 > SSL negotiation with grizzvpn.oakland.edu > Connected to HTTPS on grizzvpn.oakland.edu with ciphersuite > (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM) > Got HTTP response: HTTP/1.1 200 OK > Date: Mon, 14 Aug 2023 14:33:26 GMT > Content-Type: application/xml; charset=UTF-8 > Content-Length: 6720 > Connection: keep-alive > Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 > Set-Cookie: SESSID=83c144c4-908c-4b32-889c-3c81d660f2f6; Path=/; HttpOnly; > Secure > X-Frame-Options: DENY > Strict-Transport-Security: max-age=31536000; > X-XSS-Protection: 1; mode=block > X-Content-Type-Options: nosniff > Content-Security-Policy: default-src 'self'; script-src 'self' > 'unsafe-inline'; img-src * data:; style-src 'self' 'unsafe-inline'; > HTTP body length: (6720) > Destination form field prelogin-cookie was specified; assuming SAML POST > authentication is complete. > Prelogin form _login: "Username: " user(TEXT)=(null), "prelogin-cookie: " > prelogin-cookie(PASSWORD) > Enter login credentials > POST https://grizzvpn.oakland.edu/global-protect/getconfig.esp > Got HTTP response: HTTP/1.1 200 OK > Date: Mon, 14 Aug 2023 14:33:26 GMT > Content-Type: application/xml; charset=UTF-8 > Content-Length: 11407 > Connection: keep-alive > Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 > Set-Cookie: SESSID=824acd3b-32ae-41a7-b8e8-e59bf37533c6; Path=/; HttpOnly; > Secure > X-Frame-Options: DENY > Strict-Transport-Security: max-age=31536000; > X-XSS-Protection: 1; mode=block > X-Content-Type-Options: nosniff > Content-Security-Policy: default-src 'self'; script-src 'self' > 'unsafe-inline'; img-src * data:; style-src 'self' 'unsafe-inline'; > HTTP body length: (11407) > Portal set HIP report interval to 60 minutes). > 1 gateway servers available: > OU_VPN_Gateway (grizzvpn.oakland.edu) > Please select GlobalProtect gateway. > GATEWAY: [OU_VPN_Gateway]:OU_VPN_Gateway > POST https://grizzvpn.oakland.edu/ssl-vpn/login.esp > Got HTTP response: HTTP/1.1 200 OK > Date: Mon, 14 Aug 2023 14:33:26 GMT > Content-Type: text/html; charset=UTF-8 > Content-Length: 69 > Connection: keep-alive > Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 > Set-Cookie: SESSID=824acd3b-32ae-41a7-b8e8-e59bf37533c6; Path=/; HttpOnly; > Secure > X-Frame-Options: DENY > Strict-Transport-Security: max-age=31536000; > X-XSS-Protection: 1; mode=block > X-Content-Type-Options: nosniff > Content-Security-Policy: default-src 'self'; script-src 'self' > 'unsafe-inline'; img-src * data:; style-src 'self' 'unsafe-inline'; > HTTP body length: (69) > Failed to parse server response > Response was: > Error: Login fails (invalid session id) > > Failed to complete authentication > > Can you provide assistance, please? I have never seen this exact error message, but it appears to be in keeping with many other flavors of what I'd call "mindless state propagation" … the GlobalProtect VPN servers expect the *client* to propagate a very large number of random bits of state that the *server* really should be keeping track of on its own (and some interesting security holes result from the server not doing so 😬). Things to try: 1. Pretend to be running on Windows, rather than Linux. (`gp-saml-gui --clientos Windows` → `openconnect --os=win`). 2. Try bypassing the "portal" interface and going straight to the "gateway" interface of the GP VPN server. (`openconnect --usergroup=gateway:prelogin-cookie`) ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: AnyConnect CSD debugging
On Wed, Jul 26, 2023 at 1:17 AM Mah, Matthew Yew Mun wrote: > I am using OpenSUSE tumbleweed with openconnect 9.12-1.2 through the KDE > network manager to connect to a Cisco AnyConnect VPN using two-factor > authentication with Duo. This was working until the VPN server side recently > changed to require running the CSD trojans, and I have been unsuccessful at > reconfiguring the VPN client. As requested in the documentation, I am seeking > help debugging this issue. Please connect using the command-line OpenConnect client (start with 'openconnect -vvv --dump-http-traffic --csd-wrapper=/path/to/csd-post.sh'), which makes it much easier to debug connection problems, and share the results here. Thanks, Daniel ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: OpenConnect supported network security standards
On Mon, Jul 31, 2023 at 3:00 AM Lisa BINDER wrote: > > The Cisco AnyConnect VPN Client supports the IEEE 802.1AE standard which > allows to perform downlink MACsec between a client and a switch. > Does OpenConnect also support this feature or does it only focus on the VPN > functionality of Cisco Anyconnect? OpenConnect does not support 802.1AE/MACsec. I don't understand why Cisco client software supports *both* the VPN functionality (Layer 3 authentication, encryption, and tunnelling) as well as MACsec (Layer 2 authentication and encryption). Daniel ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: DNS server list has strange separator
On Fri, Jun 23, 2023 at 5:14 AM Dimitri Papadopoulos Orfanos wrote: > I have opened an issue here: > https://gitlab.com/openconnect/openconnect/-/issues/634 Aaron Smith, can you please test https://gitlab.com/openconnect/openconnect/-/merge_requests/483 which should fix this? > * search domains, which are typically found in the XML configuration > sent by the Fortigate, inside a single XML element, with ';' or "," as > the separator: > It would be good to get more details from Aaron, but I believe that it must indeed be the (``) XML attribute which is bizarrely delimited in this way, because: (1) the numeric DNS IP addresses *are* being correctly received (2) the split-DNS domains (``) are not actually passed along to the vpnc-script in any way ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: csd-post.sh "You are attempting to use a digital certificate not assigned to this device"
On Mon, Jun 26, 2023 at 4:56 AM Grant Williamson wrote: > I'm encountering an issue with the csd-post.sh script. When attempting > to use it, I receive the error message: "You are attempting to use a > digital certificate not assigned to this device." I would appreciate > any insights on how to add support for when a server cross checks the > MAC address functionality in the script. > Helps if I just try using what is there. Sorry. > endpoint.device.MAC[".."]="true"; Glad you figured out, but… wow. "Digital certificate not assigned to this device" is a very misleading/unclear/irrelevant error message for "you didn't tell us your MAC address." Unfortunately, OpenConnect has encountered many such similar cases where VPN servers send vague/misleading error messages when they reach an unexpected state (https://gitlab.com/openconnect/openconnect/-/blob/master/gpst.c#L672-676). It appears that their developers and administrators only test them against their official clients, and don't consider what would happen if a different client sent a different set of information. (Needless to say, these kinds of flawed assumptions are also a rich source of security vulnerabilities. 😈) ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: yubikey as 2nd factor
On Wed, Jun 7, 2023 at 7:03 AM Laszlo Fekete wrote: > cisco's own GUI vpn tool also doesn't accept the > yubikey generated characters as a 2nd password This strongly suggests that the *server* doesn't accept the Yubikey OTP as a 2nd factor. 🤷🏻♂️ > can you please help me with this? It's extremely unlikely that OpenConnect, or any other *client* software, can do anything about a *server* not being configured to accept a specific 2nd factor for your account. You'd need to talk to your VPN's administrators, and ask them to configure the server to accept the Yubikey 2nd factor, in order to change this situation. Daniel ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Send --authgroup as in initial POST request
On Wed, May 31, 2023 at 3:48 AM Popp, Thomas wrote: > The Cisco VPN server I try to connect to expects the correct authgroup to be > send as in the initial POST request, like: > > > ... > correct-auth-group > ... > > > I also failed to manipulate the initial POST request form with the > --form-entry parameter, like > --form-entry main:group-select=correct-auth-group > or > --form-entry init:group-select=correct-auth-group > > I came to realize, that openconnect is designated to send the > node, as can be seen in the code of auth.c in line 929: > https://gitlab.com/openconnect/openconnect/-/blob/master/auth.c#L929 > > However, it doesn't and I can't tell why. Any idea how to fix the problem? The way this works is a bit subtle. Providing `--authgroup Foo` on the command-line does not directly set `vpninfo->authgroup`, which means that the `` node never gets set in the *initial* XML POST request (root tag is ``). Rather, OpenConnect expects that the *response* to the initial POST will include a list of *allowed* groups. Something like this: …FoobarBaz… After receiving that list, OpenConnect attempts to match the `--authgroup Foo` from the command line to the allowed list (https://gitlab.com/openconnect/openconnect/-/blob/master/main.c#L2762-2776), and assuming a successful match it will send the `` in its *subsequent* XML POST (root tags will be either `` or `type="auth-reply"`). I have never seen a Cisco server that actually requires the `` to appear in the *initial* POST request, and am skeptical that this is what your VPN actually requires That would not allow the client to discover the allowed groups on initial connection, because the allowed groups won't be known to a client until it has connected and retrieved the list at least onece. > Otherwise the server will send a wrong path in the reponse. > > However, openconnect v9.12-0+3.1 seems to ignore the --authgroup parameter > for that purpose. Assuming that this worked without issue on older versions of OpenConnect, I suspect that the problem you are encountering is actually the same as in https://gitlab.com/openconnect/openconnect/-/issues/620#note_1415467462, namely that the server is confused by OpenConnect v9.12 offering newer SSO-based auth modes, or *STRAP* HTTP headers. Try adding `--no-external-auth` to the command-line and see if that makes a difference? ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: OpenConnect stopped working with TOTP where AnyConnect still works…
On Thu, May 25, 2023 at 12:43 PM David Raison wrote: > 1. In the http communication with the endpoint, when it comes to the > point where the web UI or the anyconnect client prompt for the token, > there is simply no field included in the XML response sent by the > server, only the element: > > < > < > < > < SSL VPN Service > < > < Enter your TOKEN password > < > < > < > < > < > < > < > < > < > < > < > < > < > < Your log shows that you're getting non-XMLPOST responses from the server. This is an od authentication mode of Cisco servers, which is vestigial and broken on most VPNs, because the admins don't know about it, and don't test against it. Quite likely, you've run into issue #544 (~= "newer Cisco servers require `--useragent=AnyConnect`, otherwise they get stuck in the usually non-functional non-XMLPOST auth path"). See more details in https://gitlab.com/openconnect/openconnect/-/issues/544#note_1222936179, and let us know if adding `--useragent=AnyConnect` addresses the problem. This is a pretty maddening issue. It's almost as if Cisco intentionally changed their servers’ responses to make authentication fail in a particularly misleading way for users of *OpenConnect*… based on the fact that we default to sending an accurate User-Agent header correctly describing the client as a non-Cisco one. ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: AnyConnect MFA code entry does not work with latest OpenConnect
On Mon, May 22, 2023 at 9:40 AM David Gstir wrote: > I’m running into issue #489 [1] with the latest OpenConnect v9.12-3-ga4f1a345. > Unfortunately none of the suggested solutions there work for me. I’ve also > tried > the --form-entry workaround from [2]. See the dump below. > > It does work fine though with the official Cisco AnyConnect Secure Mobility > Client v4.10.05095 for Linux. :-/ > > Do you have any idea or hint on how to work around that? Nope. If none of the previously discovered workarounds are helping, we're kind of out of ideas. > me@host:~/openconnect/openconnect$ ./openconnect -vvv --dump --user > MYUSERNAME --os=win --useragent 'Cisco AnyConnect VPN Agent for Windows > 4.9.0195' XX … > Got HTTP response: HTTP/1.1 404 Not Found It seems possible that this is actually issue #544 (~= "newer Cisco servers require `--useragent=AnyConnect`, otherwise they get stuck in the usually non-functional non-XMLPOST auth path"). See more details in https://gitlab.com/openconnect/openconnect/-/issues/544#note_1222936179, and let us know if that helps to address the problem. Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: NetworkManager-openconnect 1.2.10 release
On Wed, May 17, 2023 at 12:00 PM David Woodhouse wrote: > > Traxtopel (1): > Add support for OpenConnect's `--no-dtls` option to disable UDP This one has been much sought-after (https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/merge_requests/55)… Now if users are connecting from bizarre/broken networks, we can tell them "Just disable DTLS/ESP, and deal with a slow TLS-based tunnel"… like we can do with the command-line client. Of course, we still continue to make OpenConnect [even more] robust against broken/mangled connections to the VPN servers, but this will help a lot of users overcome their immediate pain points. Hooray 🙌 ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: OpenConnect 9.10 release
> Daniel Lenski (101): > … > Combine Legacy IP and IPv6 cases in GP config XML parsing> > … Unfortunately, this change introduced a bug — that is to say, I introduced a bug (🪞) — which causes GlobalProtect ESP to be entirely non-functional in OpenConnect v9.10. Thanks to nem...@gmail.com for bringing this to our attention. We've got a merge request for the one-line fix up (https://gitlab.com/openconnect/openconnect/-/merge_requests/475). @dwmw2, how 'bout an OpenConnect v9.11 release? 😬 ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Commit ba7cf175 Don't force PreventInvalidCert setting
On Fri, May 5, 2023 at 5:25 AM Grant Williamson wrote: > It appears I have an issue when attempting to edit an existing > connection using the "copr build ba7cf175", as an WARNING message is > displayed in the terminal indicating that "ca.pem uses an unknown > scheme". Will not add/import or save the ca,pem to the vpn > configuration. Are you referring specifically to this change in the NetworkManager-openconnect plugin? (https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/commit/ba7cf175) > However, when using the "nmcli" command to add the "ca.pem" file to the > connection, there are no issues, and a similar "ca.pem" file is successfully > used for wireless connections without encountering the warning message. I suspect that this is related to https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/issues/66 … When attempting to choose a cert in the GUI, but not when using 'nmcli', it forcibly prepends the user's $HOME to the front of the cert path. ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Re: Re: Building for OpenWrt
On Wed, Apr 12, 2023 at 11:29 PM lobbia wrote: > > In my case, v9.01+ doesn't work for my openwrt. My company's Cisco ASA server > prefers Azure SSO over user/pass sign-in. When using openconnect v9.01 to > connect, it propsed SSO in capacilities list and then got suck due to lack of > sufficient support e.g. GUI, TPM, Azure etc. But when using v8.20, it could > negotiate and agree on user/pass sign-in with ASA so I can connect > successfully. Yes, we're aware of this issue. I added the `--no-external-auth` option in https://gitlab.com/openconnect/openconnect/-/merge_requests/398; it will prevent OpenConnect from advertising this "less scriptable" authentication mode. (@dwmw, we should merge this one before the next release!) > Another question is, based on analysis, I see 2 more local_ids in my HTTP > POST request xml form for device-id attributes: computer-name, and > uniqu-id-global, from my client app Cisco AnyConnect v4.9.06037. Below is the > example. I don't know how difficult to extend support to these 2 new items in > code, can I just add 2 new items in auth.c and cstp.c like what you did in > the commit f73a8268 "Add CLI option --local-id, generic id_options structure, > and API function openconnect_set_id_option"? Or it's indeed much more > complicated, and have you saw this requirement also from other users and will > have a plan to support later? > > HTTP POST XML example: > > who="vpn">4.9.06037 unique-id="xxCF7963BA42EF2701DCC3C9E20007E1E30DAC9169940D88" > unique-id-global="xx4C9A04F98E4FC47BD46988" > computer-name="xxx-xxx" platform-version="10.0.22000" device_type="xx > xx">winxx-xx-xx-xx-xx-xxhttps://xxx.com/ 1. Is "computer-name" identical to the value provided by the longstanding `--local-hostname` option, or is it distinct? Is it ACTUALLY REQUIRED for your login to succeed? 2. Looks like unique-id and unique-id-global are distinct? Yes, if unique-id-global is DISTINCT AND REQUIRED, then it should just be Yet Another Thing You Can Set™ with `--local-id`. 🤕 Please submit a diff (or a merge-request on top of the https://gitlab.com/openconnect/openconnect/-/tree/add_local_id_option branch) to add these in the way that you think will make them work with your VPN, and I'll try to clean 'em up and incorporate them into the MR. Thanks! ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Re: Building for OpenWrt
On Wed, Apr 12, 2023 at 4:43 AM lobbia wrote: > > Code branch to be built: add_local_id_option > https://gitlab.com/openconnect/openconnect/-/tree/add_local_id_option (It would be a good idea to rebase this on the latest `master`, rather than just build it as-is.) I'm the author of the changes on this branch. I've had a "WIP" MR for it for about 2 years (https://gitlab.com/openconnect/openconnect/-/merge_requests/103) and have been periodically rebasing it on top of `master`. It's clearly useful/necessary to a lot of people, including another thread and couple issue reports from the past week where users needed it. However, I haven't gotten any clear feedback on the API design, which is fairly sprawling and open-ended, so I still consider it "WIP". dwmw2, would you be able to take a look at the API in your "copious spare time" and let me know if you want to try to merge it in essentially its current form? 😅 ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Think about a v9.1 release?
On Wed, Feb 22, 2023 at 7:33 PM James Ralston wrote: > > I gently echo the requests for a 9.02 release. Yep, it's pretty much just waiting for our BDFL to sign it :-) https://gitlab.com/openconnect/openconnect/-/commits/proposed-9.02 ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Connecting to anyconnect vpn - system verification
On Mon, Feb 6, 2023 at 4:04 AM Zbyněk Kačer wrote: > > I will now try to decrypt the tcp channel - there must be something > useful inside. But so far it refuses to use mitmproxy. You may well need to use TRANSPARENT proxying (https://docs.mitmproxy.org/stable/howto-transparent/) in order to force it through the proxy. - "Normal" MITM proxying: you set up a proxy via a normal proxy protocol (e.g. socks or http) and tell applications to use it. That proxy application MITM's your TLS/DTLS connections. Some applications can and do ignore it. - "Transparent" MITM proxying: your proxy runs as an unavoidable hop on the IP-based connection path between the client application and the public Internet. Individual applications cannot avoid connecting through it. This isn't quite as easy to setup as a "normal" MITM proxy, but if you're MITM'ing an application running on a VM under a Linux host, it's still pretty easy. See https://www.infradead.org/openconnect/mitm.html and https://docs.mitmproxy.org/stable/howto-transparent-vms. ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: config de GlobalProtect
On Tue, Feb 7, 2023 at 9:48 AM Rogerio Carvalho dos Santos wrote: > > Tag de config de GlobalProtect possivelmente relacionada a IPv6 > : no > Essa compilação não suporta o GlobalProtect IPv6 devido à falta de > de informações sobre como está configurado. Por favor, reporte isso > para openconnect-devel@lists.infradead.org. > # dpkg -l | grep -i openconnect > ii libopenconnect5:amd64 > 8.10-2+b1amd64open client for Cisco Thanks for the report. We've supported GlobalProtect IPv6 since v8.20: https://gitlab.com/openconnect/openconnect/-/commit/7270acd5358e200d39fe13595794f438a701b37a It's not necessary to relay these messages from old versions anymore :) Daniel ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Connecting to anyconnect vpn - system verification
I'm afraid tuning parameters does not help at all. I unsuccessfully > > tried various combinantions. > Then I dumped the /opt/cisco/anyconnect/bin/vpnui traffic, tried what > the official client sends and still no success. Hmmm. So you can see all (or almost all) of the traffic between the official client and the server, and you see NO differences between what OpenConnect sends and what the official clients send…? > What can I do more? What to dump? It's quite difficult to say without seeing some of this traffic and comparing carefully. It sounds like you've already read https://www.infradead.org/openconnect/mitm.html, and have a good idea of how to capture the traffic from the official client. > I'm able to dump (SSLKEYLOGFILE) ui's traffic and partly also the > vpnagentd's traffic but there are still some tls streams unreadable. Any idea about the *timing* or *quantity* of those TLS streams which you can't see, relative to other requests which you can see? Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Connecting to anyconnect vpn - system verification
On Fri, Jan 27, 2023 at 3:58 AM Zbyněk Kačer wrote: > So I tried openconnect openconnect --version? > So I tried > openconnect --dump-http-traffic --csd-wrapper=/tmp/csd-post.sh > gateway.host.some.server.com > > but the csd-post script seems never be called (I've inserted some echos > at the beginning). Are you 100% sure the `csd-post.sh` is an executable shell script, and that you're not missing an error about it being non-executable, or otherwise failing? Until we made improvements in recent releases (https://gitlab.com/openconnect/openconnect/-/commits/7083a0ac52a95e02b2c75180888bc29bcc9f3bae/auth.c), these errors were very easy to miss. Assuming the script is indeed executable, it's possible that your server detects that you're using a non-Cisco client, or running a not-supported OS, and simply skips over CSD and goes straight to the "limited access" mode. Try adding combinations of the following to the command line and see if they make any difference… --useragent 'AnyConnect Windows 4.10.05095' --os=win --local-hostname=HOSTNAME_OF_YOUR_OFFICIALLY_SUPPORTED_WINDOWS_LAPTOP Rinse/repeat/experiment until you hopefully find the magical combination of options/versions/identifiers (refer to https://www.infradead.org/openconnect/manual.html). > Do I have to force openconnect to post the "scan" result to the gateway > somehow? No. As far as we know, the Cisco servers either (a) require that you complete CSD before authentication will complete and you'll be able to connect the VPN tunnel, or (b) skip it. Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Multi step Cisco Anyconnect auth in a single command
On Fri, Nov 4, 2022 at 3:14 PM Ahmet Karalar wrote:
>
> Hello,
>
> I can connect to my company VPN (Cisco Anyconnect) using openconnect,
> entering credentials as the CLI asks me, however I'd like to reduce
> that to 1 step if possible. When authenticating, openconnect asks me:
> - username
> - password
> - group
> - second authentication method
> - second authentication password (a TOTP)
>
> I know that I can pass the first 3 using CLI flags or a config file,
> however I couldn't figure out how to select the second auth method and
> then pass the second auth pass to the CLI. The second authentication
> method form is a form with 4 values, of which I'd like to select
> option 4 (TOTP auth), and then I'll enter the TOTP. I'm using a
> password manager and I'll get the TOTP from there. Is there a way to
> pass option 4 for the second auth method and then the second auth
> password to openconnect, so that I can connect to the VPN using only a
> single command?
Likely yes. So, you've already got the following, right?
echo "$PASSWORD" | openconnect -u "$USERNAME" --passwd-on-stdin
--authgroup "$GROUP"
Now, you'll need to use the `--form-entry` option to specify the
second auth method (see
https://www.infradead.org/openconnect/manual.html#opt-form-entry).
First, start out by using `--dump` to extract the details of the
second form, including the name of the form and the fields+values
therein. That'll get you something like:
echo "$PASSWORD" | openconnect -u "$USERNAME" --passwd-on-stdin
--authgroup "$GROUP" --form-entry
"${2FA_FORM_NAME}:${2FA_METHOD_FIELD_NAME}=${2FA_METHOD_FIELD_VALUE}"
And then you'll need to specify `--token-mode=totp` and
`--token-secret`
(https://www.infradead.org/openconnect/manual.html#opt-token-mode) to
tell OpenConnect how to fill in the TOTP field using your token.
OpenConnect should in most cases automatically detect the field that
is supposed to be filled with the token field value. If that *doesn't*
work, then send us the complete output of `openconnect --dump` for
that second form, and we'll figure out how it differs from the current
expectations for a token field… or better yet submit a merge request
to improve
https://gitlab.com/openconnect/openconnect/blob/master/auth.c#L1004-1026).
Daniel
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Does OpenConnect give the Pulse appliance the hostname associated with user authentication?
On Thu, Nov 3, 2022 at 2:18 PM Schütz Dominik wrote: > Hi, > > I have a question in connection with OpenConnect (currently > v9.01+74+g76dc679-0+113.1) and the Pulse Secure Appliance (currently 9.1R14). > > We authenticate with "protocol=pulse" and "protocol=nc" either with username > + password (case 1) or with our smartcard (case 2). > > > We would like to add a check on our Pulse appliance, if the hostname with > which the user authenticates via username + password or smartcard is in a > certain Active Directory group, it should be moved to another role. > > My question now is whether OpenConnect gives the Pulse Appliance the host > name associated with the user authentication? Yes, this value is sent during authentication and tunnel connection/reconnection. See the source code of the precise build you are running: https://gitlab.com/openconnect/openconnect/blob/76dc679/pulse.c#L1411 BY DEFAULT, the value that OpenConnect sends on POSIX systems is the output of `uname -n`. However, the end user can easily send any other desired hostname to the server using: # This works for all supported protocols, not just Pulse openconnect --local-hostname="some.other.hostname" --protocol=pulse ... -Daniel ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Protocol F5/BigIP How to debug handshake
On Fri, Oct 14, 2022 at 7:48 AM LeJacq, Jean Pierre wrote: > > I'm trying to use OpenConnect's with the relatively new F5 protocol support. > > I'm running into problems with the initial handshake and looking for some > advice on how to debug. > > My environment is the following. I have confirmed that I can connect using the > Windows 11 F5 client. > > OS: Debian Buster (stable) > Version: OpenConnect version v9.01-1~bpo11+1. > > The problem seems to be that instead of establishing the connection, I'm > immediately redirected to a logout page saying this is an unsupported browser. > Using an explicit Windows 11 user agent string does not eliminate the warning > about a non-supported browser. Based on your site's "supported browsers" page (http://atnyulmc.org/help-documentation/quick-view-os-browser-support-matrix), it appears that they allow only a ridiculously narrow and mostly obsolete set of browsers, e.g. only the 32-bit (😵) version of IE11 (😵) on Windows 10 (😵). I played around with a few different values and couldn't get it to work, but didn't go so far as trying an actual Windows browser. Can you try to emulate ? > I'm thinking I need to provide another cookie but don't see how to determine > which one might be required. If additional parameters or requests/responses are needed to satisfy this server, and you can't figure them out by guessing or inspecting the official client… you would like need to get a MITM capture of the official client interacting with your server. I've written some documentation of how to do that here: https://www.infradead.org/openconnect/mitm.html However, since the login apparently uses an *external web browser*, it should be fairly easy for you to follow the browser/server interaction using IE/Firefox/Chrome dev tools in a supported Windows browser. If you can capture the F5_ST and MRHSession cookies from a successful authentication on Windows, then you can use them to (re)connect from OpenConnect with: openconnect --protocol=f5 my.server.com --cookie "MRHSession=VALUE; F5_ST=VALUE" Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: smartcard + configfile: how to avoid error "File name too long"?
On Wed, Oct 12, 2022 at 4:22 PM Djunzu wrote: > > I tried double quotes and single quotes. But did not thought in trying no > quotes at all. Yeah, we should update the documentation to clarify this. Or, better yet, we should update the code to accept single and/or double quotes in config files. > The error seems strange to me. But ok. Yeah, the error message is strange. It is complaining about a "file" because: 1. OpenConnect recognizes pkcs11: as the start of a PKCS11 URI 2. It does *not* recognize "pkcs11 as such (note leading "), and thus tries to interpret it as a filename. Thanks for reporting this, and we should indeed improve it. Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: [PATCH] *.sh: Fix kornsh-ism test(1) invocations
On Thu, Sep 15, 2022 at 8:00 AM Bernhard Reutner-Fischer wrote: > On Thu, 15 Sep 2022 11:54:39 +0200 > Dimitri Papadopoulos wrote: > > > Perhaps the double [[ == ]] can be changed to [ = ] in most cases, as it > > implies regular expressions might be involved - but they are not. > > The hunks in fetch.sh indeed should not be replaced. > If we were to be gentle we could grep instead, or use a case statement, > but that's probably not worth it. > > But for all the rest plain test(1) is sufficient. What I'm really asking here is… what actual problem do these changes solve? Is there, perhaps, some operating system where… (a) A version of /bin/sh supporting `==` and `[[ … ]]` is not installed by default (b) This prevents the CSD scripts from running correctly (c) But for this POSIX-ly incorrect usage, OpenConnect would otherwise work fine and allow you to connect to a Cisco server that requires CSD. If there *is* such a system, then that would provide a pretty clear rationale for changing these scripts. If there isn't, then I don't see the upside, and there could be a potential downside. It's surprisingly hard to verify that these scripts work correctly even on multiple Linux distributions, with different versions of, say, cURL, and with all pre-existing Cisco servers. Testing that things work on Android/*BSD/MacOS quickly gets overwhelming. See https://gitlab.com/openconnect/openconnect/-/commit/1b3538842757d97c6066be659cd04d3c90427ec1 and https://gitlab.com/openconnect/openconnect/-/commit/026236a2e2a241732ccbfd9abf434893c27e5af9 for examples of tiny little changes to these scripts (which had clear upsides), but nevertheless caused problems for someone, somewhere. Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: [PATCH] *.sh: Fix kornsh-ism test(1) invocations
On Wed, Sep 14, 2022 at 5:30 AM Bernhard Reutner-Fischer wrote: > > s/==/=/g > s/]]/]/g > s/\[\[/[/g > > The POSIXly correct shorthand of test(1) is [, not [[ > and string comparison is POSIXly correct =, not ==. Do note that all three of these scripts are explicitly intended+tested *only* to run under Bash… $ head -n1 android/fetch.sh trojans/csd-*.sh ==> android/fetch.sh <== #!/bin/bash ==> trojans/csd-post.sh <== #!/bin/bash ==> trojans/csd-wrapper.sh <== #!/bin/bash Is there some specific environment where your modifications make them work with a "plain" POSIX sh, where they didn't previously work correctly? ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Cannot enter 2FA code
On Tue, Sep 13, 2022 at 3:43 AM Ian Braithwaite wrote: > > On 12/09/2022 19:18, Daniel Lenski wrote: > > On Mon, Sep 12, 2022 at 6:42 AM Ian Braithwaite wrote: > >> 1. Ian, does your server also fall back to the non-XML-based > >> authentication, like Henry Luis's report and like > >> https://gitlab.com/openconnect/openconnect/-/issues/489? > > Yes it does (redirect, GET /+webvpn+/index.html). > > >> 2. Does spoofing an official Cisco Windows client change anything? > >> (openconnect --os=win --useragent 'Cisco AnyConnect VPN Agent for > >> Windows 4.9.0195')?) > > Very much - OpenConnect successfully connects, without the redirect. Excellent. Quick follow-up: does it require *both* of those arguments to connect successfully? Or is simply `--os=win` sufficient? > The server response is completely different - the hidden fields are gone > and it has a normal password field that OpenConnect handles just fine: Yay, Cisco. 🤦🏻♂️🤦🏻♂️🤦🏻♂️ > >> My best guess about the root cause here is that either it's a result > >> of a server being misconfigured/confused due to a lack of testing with > >> non-official clients, OR that it's an intentional obfuscation of the > >> authentication forms with the intention of confusing non-official > >> clients. > > Or even both :-). Agreed. "Never attribute to malice that which is adequately explained by incompetence"… but in this case there may indeed be a bit of both. Thank you, this was a great job digging into the mailing list for related past issues, and clears up some mysteries. Perhaps we should update our Cisco-specific docs at https://www.infradead.org/openconnect/anyconnect.html (source is at https://gitlab.com/openconnect/openconnect/blob/master/www/anyconnect.xml) to emphasize the need to spoof official Cisco clients to workaround authentication issues in some cases. Merge requests would be welcome :-) Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Cannot enter 2FA code
On Mon, Sep 12, 2022 at 6:42 AM Ian Braithwaite wrote: > > I'm not the original poster, but I'm experiencing the same problem. > Here's the details of the challenge form as requested. > As you guessed, OpenConnect isn't recognizing that a field needs to be > filled in > and is just continuing without it. > > I guess it's this one? > > That's a great catch. Also, a nearly identical situation was reported ~10 days ago on GitLab at https://gitlab.com/openconnect/openconnect/-/issues/489 So now we have *THREE* reports of this on real Cisco servers. > I don't know how OpenConnect is supposed to recognize it... weird it's > "hidden". > > > > -+-+-+- > Got HTTP response: HTTP/1.1 200 OK > Strict-Transport-Security: max-age=31536000; includeSubDomains > X-Content-Type-Options: nosniff > X-XSS-Protection: 1 > Content-Security-Policy: default-src 'self' 'unsafe-inline' > 'unsafe-eval' data: blob:; frame-ancestors 'self'; base-uri 'self'; > block-all-mixed-content > X-Frame-Options: SAMEORIGIN > Transfer-Encoding: chunked > Content-Type: text/xml; charset=utf-8 > Cache-Control: no-store > X-Transcend-Version: 1 > HTTP body chunked (-2) > < > < > < > < SSL VPN Service > < > < Indtast tilsendte engangskode > < > < > < > < > < > < > < > < > < > < > < > < > < > < Questions that may help resolve this issue. 1. Ian, does your server also fall back to the non-XML-based authentication, like Henry Luis's report and like https://gitlab.com/openconnect/openconnect/-/issues/489? 2. Does spoofing an official Cisco Windows client change anything? (openconnect --os=win --useragent 'Cisco AnyConnect VPN Agent for Windows 4.9.0195')?) It may be easier to follow up on the GitLab issue: https://gitlab.com/openconnect/openconnect/-/issues/489#note_1097313325 My best guess about the root cause here is that either it's a result of a server being misconfigured/confused due to a lack of testing with non-official clients, OR that it's an intentional obfuscation of the authentication forms with the intention of confusing non-official clients. Dan ps- Oddly, we also have a very similar issue with F5 VPNs (*completely different protocol*) that has popped up recently, wherein the form fields for 2FA codes get sent in a needlessly obfuscatory way: https://gitlab.com/openconnect/openconnect/-/issues/493#note_1097084348 ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: SSL connection fails with pulse protocol
On Thu, Sep 1, 2022 at 3:42 PM Ian Cornelius wrote: > This error began to appear about the time that Pulse Secure was acquired > by Ivanti. Almost certainly related to the changes in the Pulse configuration packet from the 9.1R14 and 9.1R16 server versions. (These are mystifyingly vestigial/useless changes… but that's what we've come to expect from Pulse. 😂) > I am running OpenConnect version v9.01-0+9.1 on Ubuntu 20.04.5. You'll need to build a very recent development version from the 'master' branch of https://gitlab.com/openconnect/openconnect. Thanks to contributions by users of Ivanti/Pulse servers with versions 9.1R14 and 9.1R16 (see https://gitlab.com/openconnect/openconnect/-/merge_requests/331 and https://gitlab.com/openconnect/openconnect/-/merge_requests/401), OpenConnect *should* now support those versions of the server. Feedback from additional users would be very useful. Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: dead connection after "Error in the pull function"
On Wed, Aug 10, 2022 at 1:37 PM Bernd Schubert wrote: > At least for me the interesting part is that openconnect is not sending > these ESP probes anymore then - I wonder if it is hanging. Going to get > pstack output tomorrow. > > So I enabled time stamps now (thanks for the parameter) > > 1) > ... > [2022-08-10 21:22:11] ESP session established with server > [2022-08-10 21:22:33] Send ESP probes for DPD > [2022-08-10 21:23:03] Send ESP probes for DPD > > [2022-08-10 21:42:35] Send ESP probes for DPD > [2022-08-10 21:42:42] ESP detected dead peer< Hmmm > [2022-08-10 21:42:42] UDP SO_SNDBUF: 28000 > [2022-08-10 21:43:42] Send ESP probes > [2022-08-10 21:44:42] Send ESP probes > ... > [2022-08-10 21:53:13] Send ESP probes > [2022-08-10 21:53:53] Read error on SSL session: Error in the pull function. > ... > > ===> >30 min > > > 2) > > [2022-08-10 21:57:46] ESP session established with server > [2022-08-10 21:58:01] Send ESP probes for DPD > [2022-08-10 21:58:16] Send ESP probes for DPD > ... > [2022-08-10 22:02:32] Send ESP probes for DPD > [2022-08-10 22:02:35] Read error on SSL session: Error in the pull function. > > ===> <5min > > With 2 runs (it gets late here) once around 30 min and another time > around 5 minutes. Thanks for checking this. Yeah, doesn't look like a perfectly consistent timing here. We will need to do some experimenting against our Pulse test server to try to figure out how to send keepalives to the TLS channel. Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: dead connection after "Error in the pull function"
On Wed, Aug 10, 2022 at 1:21 AM Bernd Schubert wrote: > I had found this thread > > https://askubuntu.com/questions/1273285/vpn-openconnect-pulse-disconnects-itself-in-ubuntu-20 > > and according to the discussion the issue is supposed to be resolved > with 8.20. No. I think you are referring to my comment (https://askubuntu.com/a/1368954) on that discussion. As my comment indicates, the issue that was fixed in v8.20 is… (a) Only applicable to connecting with --protocol=nc, NOT RELEVANT to connecting with --protocol=pulse. Pulse servers typically support both protocols. (b) A different kind of error. The error YOU are encountering is an error in the SSL/TLS channel of the VPN; the error described in that discussion is an error in the ESP channel. > Any idea what is going on My theory is that, because we have no known keepalive mechanism for the Pulse TLS channel, it eventually gets disconnected due to some TCP/TLS socket timeout. > … or how to debug it? (1) Add --timestamp so that you can see if there's a reproducible timing of the problem. For example, does it always occur exactly 10 minutes after you initially connect? (2) You describe this problem as a "dead connection", but it appears from your log that OpenConnect is successfully detecting the loss of connectivity on the SSL channel and reconnecting. Does the VPN continue working after reconnecting? ``` Send ESP probes for DPD Send ESP probes for DPD Send ESP probes for DPD Read error on SSL session: Error in the pull function. <-- error here SSL negotiation with Connected to HTTPS on with ciphersuite (TLS1.2)-(RSA)-(AES-128-CBC)-(SHA256) Got HTTP response: HTTP/1.1 101 Switching Protocols … ``` Dan > > > Thanks, > Bernd___ > openconnect-devel mailing list > openconnect-devel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/openconnect-devel ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: unknown form - what can I do ?
On Thu, Jul 21, 2022 at 3:04 AM Iseli Christian wrote: > The university of Lausanne recently introduced 2-factor authentication for > its VPN, and since then my working openconnect setup is failing with this > error : > > Unknown form (name 'form1', id '(null)') > Dumping unknown HTML form: > method="post"> > > value="false"> > > type="hidden"> > type="hidden" value="false"> > > > > > > > Failed to complete authentication > > The authentication seems to now be "provided" through the eduid > infrastructure of switch.ch through a shibboleth framework, if that rings a > bell to anyone... > > Should I just try to add a recognition for this form in the code and see what > happens ? > > Thanks for your help, and kind regards, > Christian Hi Christian, Which OpenConnect *protocol* are you using here? Juniper (--protocol=nc) or F5 (--protocol=f5) or Fortinet (--protocol=fortinet) are the ones that support HTML-based authentication, so most likely one of those. Also, which version of the OpenConnect client? (openconnect --version) If it's Juniper, then we've added some very rudimentary support for SSO/SAML in recent releases, but I'll wait to hear more details. It does appear that this is a form which could be automatically bypassed, given that it contains only hidden fields, unless there's some modification via a JavaScript-based layer that we're not seeing in your log. Dan ps- Perhaps worth opening an issue at https://gitlab.com/openconnect/openconnect/issues. The mailing list is not very active anymore, as you've seen. ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Network routing issue
On Fri, Jul 1, 2022 at 6:55 PM Sam wrote: > I use the vpnc-script from > https://gitlab.com/openconnect/vpnc-scripts/raw/master/vpnc-script like > this: > sudo openconnect vpn.thecompany.com > --script=/usr/share/vpnc-scripts/vpnc-script Cisco AnyConnect protocol, right? > The only way that I can make it work is to do this manually: > > sudo ip route del default via 192.168.0.1 > sudo ip route add default via 10.100.220.210 Hmmm… you're DELETING the default route through your Ethernet interface enp4s0, and creating a new default route through the tunnel interface. That's not really necessary: you should be able to simply do `sudo ip route add default dev tun0` *without* deleting the default route through the Ethernet interface. > But then the problem is if the VPN disconnects, I have to restart the > computer to get the network back! Why can't you simply recreate the default route through the Ethernet interface, or otherwise fix up the routing table? > But network routing doesn't work! It appears the fundamental issue here is that *you* want a default route via the VPN (that is, you want ALL of your IPv4 traffic to go through the VPN), but the VPN server gives you only a specific set of routes to include (known as "split-include" routes). OpenConnect + vpnc-script are, as far as I can tell, doing exactly what the VPN server is asking them to do. What happens if you connect to this VPN using an official Cisco client? Does it get assigned a default route, or does it only get assigned these specific split-include routes. Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: [EXTERNAL] Re: Cisco recommends OpenConnect
On Fri, Jun 10, 2022 at 9:57 AM David Woodhouse wrote: > But IT departments using proprietary VPN products clearly *do* trust > the likes of Cisco far more than we do, and the endorsement *is* > meaningful to them. So it doesn't hurt to highlight it. > > Especially for individual users who are seeking "permission" to use > OpenConnect against their corporate network, the endorsement could be > very useful. That's a good point. If "Cisco recommends it" gives more people cover to use OpenConnect, that's helpful. > > More seriously, I'm rather equivocal about encouraging corporate > > network IT departments to replace proprietary clients with > > OpenConnect. > > > > Those corporate network IT folks are always asking us things like, > > "Hey, OpenConnect is great! We want to use it for our whole fleet. By > > the way, can you make it so OpenConnect will check a flag sent by the > > server and then disable access to other network devices?"… > > > > … and that's the part where I have to tell them, "Look, I'm not your > > ally here, I'm your adversary. The reason I got involved in developing > > OpenConnect was to work around all of these network security policies, > > so that I could actually Get Stuff Done on the VPNs I was connecting > > to. My primary interest in such policies is documenting and explaining > > how to evade them." > > I strongly disagree with this. > > OpenConnect gives you *control*, sure. It *allows* you, as a user, to > override and bypass certain policies. Strictly speaking, so do the > proprietary clients if you try hard enough; we'd just a little more > honest about it. > > But overriding security policies is *not* its raison d'être, as you > seem to be implying above. If we don't yet support those "bar all local > network access and route to the VPN so users can't even print" or "Bar > all Legacy IP/IPv6 becaue the VPN only supports the other" features, > that is a bug/missing feature and we *do* aspire to do those things by > *default*, even if we know some users might disable them. > > I *absolutely* want to be the ally of corporate IT departments who want > to use OpenConnect and want to know that it *can* meet their > requirements. And does so out of the box without having to be tweaked. > > We are *also* the ally of individual users who want to have control of > what's on their box, and who want to use properly integrated open > source software. And where their desires mismatch with those of their > employers, that's none of our business. Much more balanced than my take. Upon reflection, I agree with all of that too. 😅 Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: [EXTERNAL] Re: Cisco recommends OpenConnect
On Mon, Jun 6, 2022 at 12:54 PM Randall Sindlinger wrote: > In any case, has this and the DevNet recommendation been added to the > https://www.infradead.org/openconnect/ page? I'm not sure where it would > best fit; but I think it > would be invaluable to give users and potential users the knowledge that > Cisco has all but formally > approved it. It sure would have helped me, at least! Hmmm. Remind me again why "the endorsement of Cisco" is an endorsement that OpenConnect would want…? 😅 More seriously, I'm rather equivocal about encouraging corporate network IT departments to replace proprietary clients with OpenConnect. Those corporate network IT folks are always asking us things like, "Hey, OpenConnect is great! We want to use it for our whole fleet. By the way, can you make it so OpenConnect will check a flag sent by the server and then disable access to other network devices?"… … and that's the part where I have to tell them, "Look, I'm not your ally here, I'm your adversary. The reason I got involved in developing OpenConnect was to work around all of these network security policies, so that I could actually Get Stuff Done on the VPNs I was connecting to. My primary interest in such policies is documenting and explaining how to evade them." > And - PS - maybe the opposite of dogfooding is catfooding; I can certainly > vouch that my dog > *strongly* prefers the cat food, anyway. :- D Hah. 😂 -Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: AW: OpenConnect does not take over MTU
On Wed, Jun 8, 2022 at 5:29 PM David Woodhouse wrote:
>
> On Wed, 2022-06-08 at 19:35 +, Schütz Dominik wrote:
> > Hi,
> >
> > sorry that the reply to the mail with the subject "Pulse with ESP has
> > problems with Kerberos Tickets" and "OpenConnect does not take over
> > MTU" took so long.
> >
> > We have found out the following about MTU with OpenConnect and
> > "protocol=pulse" (ESP):
> >
> > With OpenConnect, the MTU of the virtual adapter (tun0) is always
> > 1400, regardless of whether the MTU of the physical adapter is larger
> > or smaller.
> >
> > root@host1:~# ifconfig -a
> > tun0: flags=4305 mtu 1400
> > wlp110s0: flags=4163 mtu 1300
> >
> > root@host1:~# ifconfig -a
> > tun0: flags=4305 mtu 1400
> > wlp110s0: flags=4163 mtu 1400
> >
> > root@host1:~# ifconfig -a
> > tun0: flags=4305 mtu 1400
> > wlp110s0: flags=4163 mtu 1500
> >
> >
> > The PulseUI (9.1.R14) dynamically adjusts the MTU of the tun0.
Very similar finding in a recent GitLab issue:
https://gitlab.com/openconnect/openconnect/-/issues/447#note_981440366
It appears that when OpenConnect talks to a Pulse server, it *always*
receives an MTU of 1400. Here is the code where OpenConnect receives
the Pulse server's (alleged) MTU value:
https://gitlab.com/openconnect/openconnect/blob/master/pulse.c#L361-373
Does anyone have a counter-example, a case where OpenConnect receives
an MTU *other than* 1400 from a Pulse server?
> This is amazingly useful; thank you.
>
> One thing is missing; we don't know how (or 'if') the client *tells*
> the far end what the MTU should be.
>
> If you could get a MITM capture and look for unknown attributes in what
> their client sends to the server (or indeed in what the server sends
> back), especially looking for those MTU values, it would be very much
> appreciated.
>
> Setting the MTU on *our* side is only half the equation.
>
> We certainly *can* do that, of course, and we have the logic to fetch
> the TCP MSS and subtract from it already for other protocols; we can
> extend that to Pulse.
In my opinion, we should *never* just accept/trust an MTU value sent
by a server—at least not for a UDP based tunnel.
Too many of them are broken in their calculation method. Pulse seems
to always send 1400; GlobalProtect seems to always send ZERO.
The robust course of action:
(1) Try to estimate our MTU to the server ("outer MTU"), based on the
Internet-facing interface's MTU.
(2) Try to estimate the MTU of the tunnel ("inner MTU"), given the
overhead of the specific protocol stack. This is what the
calculate_mtu() function already does.
https://gitlab.com/openconnect/openconnect/blob/master/mtucalc.c
(3) Try to get the server to accept our value(s):
- With CSTP we have a way to tell the server what we think MTU is
between client and server over the Internet (that's what
"X-CSTP-Base-MTU" is)
- With PPP, we have a way to tell the server what we think the MTU
of the tunnel is
(https://gitlab.com/openconnect/openconnect/blob/master/ppp.c#L400-415)
- With Juniper, Pulse, GlobalProtect, Array(?) we have no known
way to tell the server what we think the MTU should
(4) Once the tunnel is up, VERIFY the "inner MTU" by doing a binary
search to find the biggest packet size that we can actually get
through.
- For Cisco DTLS, we already do this:
https://gitlab.com/openconnect/openconnect/blob/master/dtls.c#L473
- For GP ESP, we COULD do this using the probe packets, since
they're just pings (ICMP Echo-Request), which we can fill up with
arbitrarily-large payloads:
https://gitlab.com/openconnect/openconnect/blob/master/gpst.c#L1332
- For PPP DTLS *or* TCP, we COULD do this using LCP Echo-Request,
since it's legal to add an arbitrarily-large payload there too:
https://datatracker.ietf.org/doc/html/rfc1661#section-5.8
- For Juniper/Pulse ESP, I'm not sure. The (pre-encapsulation)
probe packet is just a single zero byte. If we send, let's say, 500
zero bytes, will the server echo that back as needed?
- Array: ??
(5) Hope/pray that the tunnel isn't asymmetrical, or that the server
hasn't ended up with its own wrong idea of the MTU, and that it's not
trying to send back overly-large packets to us, which are getting
dropped.
-Dan
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Aruba VIA VPN support
On Mon, Jun 6, 2022 at 1:27 PM Daniel Pou wrote: > > I will give it a shot. The possibly oddball thing about VIA, is the > "hybrid" nature, that it "automatically scans and selects the best, > secure connection to terminate traffic" where it supports IPSec/SSL. Yes, that's typical marketing fluff/BS for proprietary VPNs. Most likely, it just means that they… (a) do the authentication over HTTPS (b) try to establish a tunnel over ESP-over-UDP (ESP is a component protocol of the IPSec suite) (c) fall back to an SSL/TLS tunnel if ESP-over-UDP doesn't work That's entirely equivalent to how Juniper or GlobalProtect work (https://www.infradead.org/openconnect/juniper.html or https://www.infradead.org/openconnect/globalprotect.html). We shouldn't have too much trouble integrating such a protocol into OpenConnect once you've figured out some of the details. I recently wrote up some documentation on how to analyze proprietary VPN protocols, using tools like mitmproxy: https://www.infradead.org/openconnect/mitm.html Dan PS- All or nearly all client-server/remote-access VPNs work in the same fundamental way. The user-visible details could mostly be described as "bugs" or "annoyances". From my 2020 talk on this (https://datapdx.org/2020/08/28/september-2020-openconnect): - All remote-access VPNs basically work like I’ve just described. - There are many small differences among end-user client software interfaces, which can be very tedious and annoying if you have to use several VPNs. - Under the hood, there are tons of essentially superficial differences in the protocols: formatting of configuration data exchange, packet encapsulation; also some functional details that can affect reliability and versatility. - They have so many common features that it should be possible to write… - Software that can connect to all of them in a way that’s entirely equivalent to the end user. → OpenConnect ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Aruba VIA VPN support
On Mon, Jun 6, 2022 at 9:00 AM Daniel Pou wrote: > > After a cursory inspection, I have not found any request to add > support for Aruba VIA VPN protocol in issues or the mailing list. I am > curious if anyone has considered or made any effort so far? I am > trying to look through the links referenced on observing from the main > site in the mean time. Very interesting. I had never heard of this VPN protocol before. Definitely seems like it'd be worth adding support for. I write and maintain a tool called what-vpn which can be used to sniff/survey various SSL/TLS-based VPNs, largely so that we can try to figure out what fraction of VPNs out there are supported by OpenConnect (currently >90% 😎): https://github.com/dlenski/what-vpn#2021-results I just added a rudimentary detector for Aruba VIA networks VPNs in https://github.com/dlenski/what-vpn/commit/15cc61a1956270c57c574b956ec2faa6bc7be386 I tested it on a couple university VPNs where I could find public documentation that they are indeed running an Aruba VPN… would you mind testing to see if it works on yours? ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: How can I specify a realm with "--protocol=pulse"?
On Wed, May 4, 2022 at 11:17 AM Schütz Dominik
wrote:
> yes, it works with "--authgroup" for "--protocol=nc" and "--protocol=pulse".
We need better documentation for the `--authgroup` option.
Its current description is very Cisco-specific, which makes it
completely non-obvious that it will work with other protocols as well
("realm" for Juniper/Pulse/Fortinet; "domain" for F5, etc). You're not
the first user to ask about this.
Here's an MR to improve its documentation:
https://gitlab.com/openconnect/openconnect/-/merge_requests/387
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: DTLS handshake failed: Error in the push function
On Sun, Jun 5, 2022 at 10:04 AM Fourhundred Thecat <400the...@gmx.ch> wrote: > when I connect with openconnect, I am getting these errors: > > DTLS handshake failed: Error in the push function. > (Is a firewall preventing you from sending UDP packets?) What version of OpenConnect? `openconnect --version` > the connection works, but I suspect the firewall is blocking udp packets > > Can I et rid of the error messages? > Can I, for instance, specify to connect tcp only? Yes, use the `--no-dtls` flag. https://www.infradead.org/openconnect/manual.html ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Cisco recommends OpenConnect
On Fri, Jun 3, 2022 at 1:44 PM Randall Sindlinger wrote: > > If you aren't aware, I just found that Cisco's DEVNET has a genuine > recommendation to use > OpenConnect. Cisco's own IP phones, at least model "SPA-525g", use the OpenConnect client. https://gitlab.com/openconnect/ocserv/-/issues/51#note_12193848 Yes, you read that right: despite the proprietary AnyConnect clients and servers having been developed at the same company, someone at Cisco apparently found it easier to make their own IP phones speak that protocol by using OpenConnect's reimplementation of that protocol. Which is frankly not that surprising to me… from working on OpenConnect for years and studying many proprietary VPN clients, all the evidence I've seen suggests they're all dumpster fires of bad designed-by-committee code. What's the opposite of "dogfooding"? 🤔 Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Cannot enter 2FA code
On Thu, May 12, 2022 at 2:19 PM Henry Luis wrote: > Today, openconnect prompts me for the 2FA code but does not give me the > chance to enter it (see the "Enter PASSCODE" line below). The same happens > when I use the network manager Gnome GUI. This used to work as of yesterday. Clearly, something must have changed on your *server*, because nothing changed about the client *software* that you're running… right? My educated guess from the limited information here is that the form field sent by the server to request the 2FA code has changed in such a way that OpenConnect doesn't recognize it as a fillable field anymore. But that's only a guess. 1. Use `openconnect -vvv --dump` to add copious additional debugging information. To figure this out, we'll particularly want to see the details of the "challenge"/2FA form, sent in response to the initial `POST https://my-vpn-dot-com/+webvpn+/index.html`. 2. You're using an old version of OpenConnect, as shown by the exact error messages. What does `openconnect --version` show? 3. Newer versions have better error messages *and* work with servers with newer authentication-related behavior. I'd recommend building v9.01 from source (https://www.infradead.org/openconnect/building.html) and testing that, to see if it makes your connection work again. Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: How can I specify a realm with "--protocol=pulse"?
On Wed, May 4, 2022 at 3:11 AM David Woodhouse wrote: > > On Wed, 2022-05-04 at 09:36 +, Schütz Dominik wrote: > > Hi, > > > > how can I specify a realm with "--protocol=pulse"? > > # output without specify realm > > Choose Pulse user realm: > > Realm: > > [REALM_xxx_Productive|REALM_xxx_Limited_Initial_Network|REALM_xxx_Limited_Machine_Network]:REALM_xxx_Limited_Machine_Network > > > > > > With "--protocol=nc" I specify the realm as follows: > > # output without specify realm > > frmLogin > > realm > > [REALM_xxx_Productive|REALM_xxx_Limited_Initial_Network|REALM_xxx_Limited_Machine_Network]:REALM_xxx_Limited_Machine_Network > > > > # command with realm > > dominik at host1:~$ sudo openconnect --script=/root/vpnc-script > > --protocol=nc --form-entry=frmLogin:realm=REALM_xxx_Limited_Machine_Network > > https://vpn-gateway/linux > > For pulse I think you want '-F pulse_realm_entry:realm=REALM_xxx_Foo' It's not necessary to use -F/--form-entry here ☺ It should also work fine with `--authgroup` (https://gitlab.com/openconnect/openconnect/blob/master/pulse.c#L785-787), e.g. `--authgroup REALM_xxx_Foo`. The name "auth group" originally came from Cisco, but the option `--authgroup` now works with all other protocols that allow the user to select some kind of dropdown. We even have tests to verify that the client propagates this value as expected, in all the protocols where it's supported and where we have authentication tests. Juniper/NC: https://gitlab.com/openconnect/openconnect/-/blob/master/tests/juniper-auth#L45-47 GlobalProtect: https://gitlab.com/openconnect/openconnect/-/blob/master/tests/gp-auth-and-config#L44-46 F5: https://gitlab.com/openconnect/openconnect/-/blob/master/tests/f5-auth-and-config#L50-52 Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: pulse protocol and microsoft 2fa ?
On Tue, Mar 29, 2022 at 2:50 PM Athanasios Silis wrote: > > Hi everyone, > this is not a new question as I see but maybe the combination of options is. > So my company has been using the pulse protocol for its vpn service. > Microsoft 2FA will soon become unavoidable for the connection. > > I've installed the pulseUI client to see how it works and I must say > I'd prefer it if I avoided any gui client. Openconnect has been great > so far and I would like to keep it that way. > > S, is there any solution to authenticate for the vpn through my > microsoft account and connect to my company's vpn and do all that > through the cli ??? :) > > I've seen some gp and saml wrapper scripts > https://github.com/dlenski/openconnect > https://github.com/libcthorne/samlwebcookie > so i;m hopeful something exists for microsoft 2fa as well. As of the recently-released OpenConnect v8.20, we have *partial* support for Microsoft 2FA with the older Juniper/NC protocol, which most Pulse servers support in addition to the newer Pulse protocol. See recent comment with more pointers: https://gitlab.com/openconnect/openconnect/-/issues/385 Please test and give us feedback. I recommend reading and engaging on these issues if you encounter problems: https://gitlab.com/openconnect/openconnect/-/issues?sort=updated_desc&state=all&label_name[]=External+Auth/SAML/SSO Because the core OpenConnect developers don't have access to VPNs implementing every one of these new types of authentication, our ability to support and debug these is very limited, and we rely mostly on users' contributions. Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Trying to build openconnect 8.20 on ubuntu 20
On Thu, Mar 17, 2022 at 2:30 AM Dimitri Papadopoulos wrote: > One could re-enable TLS < 1.2, but it's always the same story: I don't > want to do that for a whole system, just for specific (client) software. Agreed. I've got a (work-in-progress) MR which adds additional warning messages for these OpenSSL version, and suggests the use of `--allow-insecure-crypto` which sets the OpenSSL security level to ZERO just for OpenConnect: https://gitlab.com/openconnect/openconnect/-/merge_requests/346 Would be great to include some of your proposed documentation updates in this as well. Dan Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Trying to build openconnect 8.20 on ubuntu 20
On Tue, Mar 15, 2022 at 12:12 PM Daniel Lenski wrote: > This patch suggests that the "OpenSSL security level" could be the > culprit: if the "OpenSSL security level is set to >=2, then vanilla > OpenSSL 1.1.1f will allow old/bad/Cisco DTLS, but Debian/Ubuntu > OpenSSL 1.1.1f will *not* allow it: This thread confirms that the change was intentional in Ubuntu 20.04: https://discourse.ubuntu.com/t/default-to-tls-v1-2-in-all-tls-libraries-in-20-04-lts/12464/5 > Contrary to the default in ubuntu 20.04 tls 1.0 and 1.1 are only allowed on > security level <2 instead of <4. Also the default security level of 1 was > raised to 2. Furthermore, as of 1.1.1k, *Debian* picks up a similar patch: https://sources.debian.org/patches/openssl/1.1.1k-1+deb11u1/ So both TLS <1.2 and DTLS <1.2 are disabled by default, and the OpenSSL security level is set to 2 by default, in Ubuntu 20.04+ and Debian sid. We'll have to warn users about this… yay. 🤦🏻♂️ Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Trying to build openconnect 8.20 on ubuntu 20
On Tue, Mar 15, 2022 at 12:38 AM Dimitri Papadopoulos
wrote:
>
> Hi,
>
> It definitely looks like an Ubuntu bug. I can reproduce this issue when
> building against the OpenSSL library that ships with Ubuntu 20.04:
>
> $ ./configure \
> --prefix=/my/path/openconnect \
> --with-vpnc-script=/my/src/vpnc-scripts/vpnc-script \
> --with-openssl
> $
> $ make check
> [...]
> FAIL: bad_dtls_test
>
>
>
> This failure disappears after building against a vanilla OpenSSL 1.1.1f:
>
> $ ./configure \
> --prefix=/my/path/openconnect \
> --with-vpnc-script=/my/src/vpnc-scripts/vpnc-script \
> --with-openssl=/my/src/openssl-1.1.1f
> $
> $ make check
> [...]
> PASS: bad_dtls_test
Great find, Dimitri! Thank you.
Per https://packages.ubuntu.com/focal-updates/libssl-dev, this package
seems to come straight from Debian with no Ubuntu modifications. A
glance at the debian/patches/ directory from
http://archive.ubuntu.com/ubuntu/pool/main/o/openssl/openssl_1.1.1f-1ubuntu2.11.debian.tar.xz
suggests that there are a pretty stupendously large number of patches
applied against the upstream OpenSSL 1.1.1f. ☹
This patch suggests that the "OpenSSL security level" could be the
culprit: if the "OpenSSL security level is set to >=2, then vanilla
OpenSSL 1.1.1f will allow old/bad/Cisco DTLS, but Debian/Ubuntu
OpenSSL 1.1.1f will *not* allow it:
tls1.2-min-seclevel2.patch-Description: TLS versions below 1.2 are not
permitted as security level 2.
tls1.2-min-seclevel2.patch-
tls1.2-min-seclevel2.patch-Index: openssl-1.1.1d/ssl/ssl_cert.c
tls1.2-min-seclevel2.patch-===
tls1.2-min-seclevel2.patch openssl-1.1.1d.orig/ssl/ssl_cert.c
tls1.2-min-seclevel2.patch-+++ openssl-1.1.1d/ssl/ssl_cert.c
tls1.2-min-seclevel2.patch-@@ -956,18 +956,12 @@ static int
ssl_security_default_callback
tls1.2-min-seclevel2.patch- }
tls1.2-min-seclevel2.patch- case SSL_SECOP_VERSION:
tls1.2-min-seclevel2.patch: if (!SSL_IS_DTLS(s)) {
tls1.2-min-seclevel2.patch--/* SSLv3 not allowed at level 2 */
tls1.2-min-seclevel2.patch--if (nid <= SSL3_VERSION && level >= 2)
tls1.2-min-seclevel2.patch--return 0;
tls1.2-min-seclevel2.patch--/* TLS v1.1 and above only for
level 3 */
tls1.2-min-seclevel2.patch--if (nid <= TLS1_VERSION && level >= 3)
tls1.2-min-seclevel2.patch--return 0;
tls1.2-min-seclevel2.patch--/* TLS v1.2 only for level 4
and above */
tls1.2-min-seclevel2.patch--if (nid <= TLS1_1_VERSION && level >= 4)
tls1.2-min-seclevel2.patch-+/* TLS v1.2 only for level 2
and above */
tls1.2-min-seclevel2.patch-+if (nid <= TLS1_1_VERSION && level >= 2)
tls1.2-min-seclevel2.patch- return 0;
tls1.2-min-seclevel2.patch- } else {
tls1.2-min-seclevel2.patch:-/* DTLS v1.2 only for level 4
and above */
tls1.2-min-seclevel2.patch:-if (DTLS_VERSION_LT(nid,
DTLS1_2_VERSION) && level >= 4)
tls1.2-min-seclevel2.patch:+/* DTLS v1.2 only for level 2
and above */
tls1.2-min-seclevel2.patch:+if (DTLS_VERSION_LT(nid,
DTLS1_2_VERSION) && level >= 2)
tls1.2-min-seclevel2.patch- return 0;
tls1.2-min-seclevel2.patch- }
tls1.2-min-seclevel2.patch- break;
Since https://gitlab.com/openconnect/openconnect/-/merge_requests/158,
the `--allow-obsolete-crypto` flag is supposed to set the OpenSSL
security level to ZERO. Does adding this flag make the test pass when
using the Ubuntu-distributed libraries?
We decided in
https://gitlab.com/openconnect/openconnect/-/issues/211#note_492787698
that *unconditionally* setting the OpenSSL security level to ZERO was
not a good idea. If Debian-based distros are now preventing
old/bad/Cisco DTLS from working, then we're definitely going to have
to update our docs to reflect this. And maybe rethink the decision not
to unconditionally set to zero.
Dan
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Trying to build openconnect 8.20 on ubuntu 20
On Mon, Mar 14, 2022 at 3:41 AM Dimitri Papadopoulos Orfanos wrote: > I guess libgnutls28-dev was initially missing. By installing it, your > build switched to GnuTLS, which appears to support the broken Cisco DTLS > version, unlike OpenSSL version 1.1.1f (the version shipping with Ubuntu > 20.04). > > So it's really an issue of building against OpenSSL vs. GnuTLS. It's > definitely worth documenting the OpenSSL 1.1.1f issue here: > - https://www.infradead.org/openconnect/anyconnect.html > - > https://gitlab.com/openconnect/openconnect/-/blob/master/openssl-dtls.c#L774-784 Exactly. Without a bit more investigation, I'm hesitant to categorically state that 1.1.1f is buggy (rather than "1.1.1f as distributed by Ubuntu"), because the support for "Cisco/pre-1.0 DTLS" seems to get broken inadvertently so often, due to being the most unloved and obscure variant of TLS/DTLS around. By the way, our error message links to http://rt.openssl.org/Ticket/Display.html?id=2984, which appears to be a bug tracker that no longer exists and isn't cached by Wayback Machine 🤦🏻♂️. @dwmw2, are there any more details on that ticket that you still have? Perhaps details on *when/where/how* the OpenSSL support for "Cisco/pre-1.0 DTLS" was broken? > By the way, the above documentation still refers to patching and > rebuilding OpenSSL 0.9.8, 1.0.0, 1.0.1. Perhaps we should consider > retiring that part of the documentation, as versions 0.9.8, 1.0.0, 1.0.1 > have reached EOL. Only 1.0.2 benefits from extended support. While the > source code should probably support prior versions, the documentation > should instead recommend patching/building supported versions of OpenSSL > (> 1.1.1 with regular support and 1.0.2 with extended support): > https://www.openssl.org/policies/releasestrat.html Agreed. ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: MFA with GlobalProtect
On Fri, Mar 4, 2022 at 9:55 AM Adam Mercer wrote: > > Hi > > We use a GlobalProtect VPN at work and they recently required the > usage of Microsoft MFA when connecting, I've been trying to get this > working with openconnect but have been having problems. I've built the > latest client from git and am using: > > # openconnect --protocol=gp vpn.address.com > > and this results in: > > SAML REDIRECT authentication is required via > https://login.microsoftonline.com//saml2?SAMLRequest=RelayState=%3D%3D > When SAML authentication is complete, specify destination form field > by appending :field_name to login URL. > > If I visit the URL in my browser I see > > Login Successful! > > How do I determine field_name from this? This is an area of active and ongoing development in OpenConnect, due to the recent proliferation of VPNs that use single-sign-on services (like Microsoft's or Okta's) for authentication. For now, I recommend that you try out https://github.com/dlenski/gp-saml-gui, which is a front-end script that I wrote to do the authentication via a graphical pop-up, and then to pass the correct arguments along to OpenConnect. There are other scripts, but this is the one that I wrote and understand, and there is also work-in-progress to integrate this into OpenConnect itself but… don't hold your breath 😁. Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Trying to build openconnect 8.20 on ubuntu 20
On Mon, Mar 7, 2022 at 3:44 PM Daniel Lenski wrote: > > On Fri, Mar 4, 2022 at 6:25 AM Eveno, Manuel wrote: > > $ cat openconnect-8.20/tests/test-suite.log > > - Output : > > FAIL: bad_dtls_test > > 1. If you just want to *use* OpenConnect with a Fortinet VPN, then > this failing test result does not matter. > > This particular test exists only to verify that the "ekstra speshul" > weird/broken/non-standard/pre-1.0 version of DTLS used by old **Cisco > AnyConnect** VPNs is working correctly. Linux distributions and crypto > libraries keep forgetting that this version of DTLS is sadly still > needed, so they frequently break it. And we have to figure out who to > ask to get the libraries fixed. 😔 Our continuous integration pipeline builds against Ubuntu 18.04 (https://gitlab.com/openconnect/openconnect/-/jobs/2115365633), which distributes OpenSSL 1.1.1 (https://packages.ubuntu.com/bionic-updates/libssl-dev)… but Ubuntu 20.04 distributes OpenSSL 1.1.1f (https://packages.ubuntu.com/focal-updates/libssl-dev). @David, perhaps we need to add OpenSSL 1.1.1f to our list of OpenSSL versions whose DTLS implementations don't work with Cisco? - https://www.infradead.org/openconnect/anyconnect.html - https://gitlab.com/openconnect/openconnect/-/blob/master/openssl-dtls.c#L774-784 Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Trying to build openconnect 8.20 on ubuntu 20
On Fri, Mar 4, 2022 at 6:25 AM Eveno, Manuel wrote: > Trying to build openconnect 8.20 on ubuntu 20 What is "ubuntu 20"? I assume you mean 20.04 / focal? Running `lsb_release -a` should clarify. > I need to test the fortinet protocol. > I'm trying to build openconnect for the downloaded package. > > But when running the "make" command it fails on tests. > > > > $ cat openconnect-8.20/tests/test-suite.log > - Output : > FAIL: bad_dtls_test 1. If you just want to *use* OpenConnect with a Fortinet VPN, then this failing test result does not matter. This particular test exists only to verify that the "ekstra speshul" weird/broken/non-standard/pre-1.0 version of DTLS used by old **Cisco AnyConnect** VPNs is working correctly. Linux distributions and crypto libraries keep forgetting that this version of DTLS is sadly still needed, so they frequently break it. And we have to figure out who to ask to get the libraries fixed. 😔 This is not used at all when connecting to Fortinet VPNs, so you can Just Ignore It. 2. If you want a fully-working build of OpenConnect that *can* work with old Cisco VPNs, in addition to Fortinet VPNs, then you should build again GnuTLS rather than OpenSSL (`sudo apt install libgnutls28-dev`). While OpenConnect can use either OpenSSL or GnuTLS, we collaborate more closely with the GnuTLS developers than the OpenSSL ones, so we run into fewer problems like this with GnuTLS ☺ Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Thanks for fixing issues/322
On Wed, Dec 29, 2021 at 7:16 PM Scott wrote: > > Regarding this bug: https://gitlab.com/openconnect/openconnect/-/issues/322 > > I've been having dropouts for 18 months, reconnecting 20-30 times a day, > I just want to say thanks so much for fixing it! Much appreciated. Glad to hear it. We really need to get a release out, because this (Juniper/NC rekey) has been broken since OpenConnect v8.04 and confusing/annoying/affecting a bunch of users. Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: OpenConnect on a Windows11-ARM VM
On Tue, Dec 14, 2021 at 10:08 PM Daniel Lenski wrote: > > What you've specified, `--os=windows`, is not a value that OpenConnect > understands; per the manual, > (https://www.infradead.org/openconnect/manual.html), `--os=win` is the > legal value. Does that work? Have you had a chance to test this? Does it make a difference? Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: OpenConnect on a Windows11-ARM VM
On Tue, Dec 14, 2021 at 1:47 PM Dev Faye wrote: > I'm not a programmer at all? Though, it's been nearly 1 week I'm going > back and forth, trying to get at least one VPN client working on my > virtual machine. I've tried built-in VPN, CheckPointCapsule, > GlobalProtectUWP, GlobalProtect MacOS client, no success. Plus, I > didn't succeed deploying gp-saml-gui, due to repetitive python > dependencies I couldn't solve :( I assume you're the same person who started this thread, asking for help getting gp-saml-gui working? https://gitlab.com/openconnect/openconnect/-/issues/53#note_766233185 > Now back to OpenConnect. Exactly what are you trying to do or illustrate here? I *think* that what you are doing is trying to "manually" follow the SAML login behavior since you can't use gp-saml-gui to automate it… 1. Use `openconnect` to fetch the SAML login URL 2. Open that URL in a browser 3. Follow the auth forms, and inspect their source, until you get either a 'prelogin-cookie' or a 'portal-userauthcookie' (https://github.com/dlenski/gp-saml-gui/blob/master/gp_saml_gui.py#L131) from the server 4. Plug that cookie back into OpenConnect to finish the login So… *is* that what you're trying to do? I can't be sure. Assuming that *is* what you're trying to do, your last command is the most close-to-correct one. You can tell that because it gets further than all the preceding ones. It's the only one that doesn't "fail to complete authentication." Instead it fails like this: > C:\Program Files\OpenConnect>openconnect --protocol=gp --usergroup=gateway:prelogin-cookie --user=91000318@CORP --os=windows --passwd-on-stdin --cookie-on-stdin -vvv --verbose … POST https://fr.ras.biomerieux.com/ssl-vpn/getconfig.esp … Response was: errors getting SSL/VPN config The reason this one is failing is because it doesn't like something about the client parameters. Usually, specifying the wrong OS is the culprit. GlobalProtect servers are maddeningly stupid, inconsistent, and vague about reporting this (https://gitlab.com/openconnect/openconnect/-/commit/e2f574a5f5f06a2364ff65f7a13721f79bf4beef for more examples), so it's very hard to give an error message that clearly identifies the root cause. What you've specified, `--os=windows`, is not a value that OpenConnect understands; per the manual, (https://www.infradead.org/openconnect/manual.html), `--os=win` is the legal value. Does that work? We should improve OpenConnect by giving the user an error message if an illegal value is specified for `--os=...`, to make it easier to detect this problem. Changes to do this: https://gitlab.com/openconnect/openconnect/-/merge_requests/310 -Dan > > Now back to OpenConnect. > > Platform : Windows11 on ARM, hosted on a ParallelsDesktop17 VM > installed on MacOS 12.1 on ARM > OpenConnect version v8.10-727-gbd6a7e71 > My company authentication requires SAML with 2FA. > > =__=_= > first > C:\Program Files\OpenConnect>openconnect --protocol=gp > --usergroup=portal --user=91000318@CORP --os=windows --passwd-on-stdin > portal.ras.biomerieux.com > ||myPassword|| > POST > https://portal.ras.biomerieux.com/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Windows > Connected to 193.240.245.231:443 > SSL negotiation with portal.ras.biomerieux.com > Connected to HTTPS on portal.ras.biomerieux.com with ciphersuite > (TLS1.2)-(RSA)-(AES-256-GCM) > SAML REDIRECT authentication is required via > https://auth.biomerieux.com/adfs/ls/?SAMLRequest=lZFPT8MwDMW%2FSpX7mjRtmbDWSmU7MGmIai0cuKCsNSxSm5Q4Rfv4dBuIP4dJHC0%2FPz%2F%2FvCDVdwMUo9%2BbLb6NSD449J0hODUyNjoDVpEmMKpHAt9AVdxtQIYCBme9bWzHgoIIndfWLK2hsUdXoXvXDT5sNxnbez8QcD5Y51UXOkXhTttJpHE8hI3tIUlifnSVglclL5YVC1ZTEm3U0fPbQU0x%2F8xy1b4Q74izYL3K2HNyJVGKWCQtYpymSmEaqyaOcNe08%2FhaTjKiEdeGvDI%2BY1LIaBbJWZTUUkAyB5E%2BsaD8vOxGm1ab18sYdmcRwW1dl7PyvqpZ8IiOTtEnAcsXR5hwWux%2B4L1sq76YsvyfBBf8x778XP3%2Bcf4B&RelayState=dBNlABd8MWBhYWNjYWQxMDNkZDA5MDFlOTc0NjE5NDQ1NGM0NmIwNg%3D%3D&SigAlg=http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256&Signature=Tie5OOdnOBxSW5ROLcA0hoxrjDf2%2FPYMgFiuTP1cGZWrCistZ9LiuJsmjIWZmv74VF%2F38wJN7Z8q6JO3GMP%2Fpu4lR360HQMh6liR06mepWvWacktgtbEiDF5F6OlE7icedJDdgemJ1LuuAS7pxSS1oHz1dXS6tI%2B4EAb0Bc24iyCZRIbse5jwmljZcp9MnDzJv86ibtI%2FSl%2B7bYaG94Vc53syLsexQj%2FDZ%2F9tV8ZFJz5j1gleVQlsHUm2YwKF3Nxkfv%2BCLrn128nQC%2B17WBloQmEcftY3szjbCEVv5z9qFwQhrHT6hB7d4Y%2Fu5fq9G4VMKSuDV0AJHC%2B5aAJmGvg2A%3D%3D > When SAML authentication is complete, specify destination form field > by appending :field_name to login URL. > Failed to complete authentication > > then > C:\Program Files\OpenConnect>openconnect --protocol=gp > --usergroup=portal:prelogin-cookie --user=91000318@CORP --os=windows > --passwd-on-stdin --cookie-on-stdin portal.ras.biomerieux.com > ||myPassword|| > uRCVTTz/E/kAGrw9y+PGRapC0o0RvSww2n957aU8ysipJ1JasFhJ2CChMlupz/u/ > POST https://por
Re: openconnect on macOS
On Tue, Nov 30, 2021 at 7:36 AM Frank Winkler wrote: > I've been using oc on Linux and macOS for quite a while now and it > worked fine so far. Since I upgraded to macOS 12, it seems that oc is > crashing the entire network stack after running for some time. Can you clarify what "crashing the entire network stack" means? Ideally with logs etc. Are you using the utun driver, as recommended for all modern versions of MacOS? https://www.infradead.org/openconnect/building.html > Connections get slower and slower and then new connections cannot be > created, ending up with socket errors. I didn't find a way to cure the > system unless I reboot. Is there a known incompatibility to macOS 12? We haven't had any previous reports of system-wide degradation like this, as far as I know 🤷🏻♂️. https://gitlab.com/openconnect/openconnect/-/issues None of the core OpenConnect developers regularly use MacOS, and we don't have any good way to do automated testing on MacOS, so we rely on user reports for this. > And as the last update is one and a half years old, is there any further > development? Yes, lots and lots of it, including new protocols, performance and usability improvements, and more. See https://gitlab.com/openconnect/openconnect and links to build instructions from there. Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Error in the push function.
> I can offer a bit of context. I had possession of this laptop originally,
> running Ubuntu 18.04. I initially configured the VPN connection a few years
> ago, and it worked successfully on a day-to-day basis up until I last tested
> it a few weeks ago. (I have forgotten any headaches that may have been
> involved in the initial setup.) It should be the current version in the
> Ubuntu 18.04 repos, so... openconnect 7.08?
>
> In case it's relevant, the VPN connection requires a smart card with a PIN
> for authentication.
>
> Upon leaving the organization, I transferred the laptop to Amirali (created a
> new user, deleted my old one), and unfortunately the VPN connection didn't
> "just work" for him. We tried bypassing the GUI by running openconnect from
> the command line, which resulted in the output Amirali has shown previously.
> I'm confident I've never seen the "Error in the push function" message
> before, so I suggested Amirali reach out to the OpenConnect community for
> assistance.
Huh. So, running the EXACT SAME openconnect binary on the EXACT SAME
laptop and connecting to the EXACT SAME organization's VPN… it
work(ed,s) for one of you, but not for the other? 🤷🏻♂️
That's interesting and exceedingly strange, but we'd still need a
bunch more information here in order to make any progress.
The CLI is indeed much better than the GUI for logging and debugging.
Please confirm *exactly* what version you're running (`openconnect
--version`) including what crypto library it's built against.
If it is OpenConnect v7.08, that's very old, and there have been a
bunch of smartcard-related fixes since then. Try building the latest
development version from source
(https://gitlab.com/openconnect/openconnect/commits/master), or
failing that, at least upgrade to v8.10 (the latest release, although
it's now >> 1 year old).
If upgrading to a newer version doesn't help, a detailed log
(`openconnect -vvv --dump-http-traffic`) will likely provide more
information.
-Dan
On Thu, Nov 18, 2021 at 7:17 PM Mitchell Dorrell wrote:
>
> Hello Dan,
>
> I can offer a bit of context. I had possession of this laptop originally,
> running Ubuntu 18.04. I initially configured the VPN connection a few years
> ago, and it worked successfully on a day-to-day basis up until I last tested
> it a few weeks ago. (I have forgotten any headaches that may have been
> involved in the initial setup.) It should be the current version in the
> Ubuntu 18.04 repos, so... openconnect 7.08?
>
> In case it's relevant, the VPN connection requires a smart card with a PIN
> for authentication.
>
> Upon leaving the organization, I transferred the laptop to Amirali (created a
> new user, deleted my old one), and unfortunately the VPN connection didn't
> "just work" for him. We tried bypassing the GUI by running openconnect from
> the command line, which resulted in the output Amirali has shown previously.
> I'm confident I've never seen the "Error in the push function" message
> before, so I suggested Amirali reach out to the OpenConnect community for
> assistance.
>
> I hope this additional context helps!
> Mitchell Dorrell
>
> On Thu, Nov 18, 2021, 20:25 Daniel Lenski wrote:
>>
>> On Thu, Nov 18, 2021 at 1:33 PM Amirali Hossein
>> wrote:
>> > How should I resolve "Error in the push function."?
>>
>> Can you give us more information? Start with the complete output of
>> `openconnect --version`, and what operating system you're running on.
>>
>> All I can tell from the messages ("SSL connection failure" and "Failed
>> to obtain WebVPN cookie") is that you're using a GnuTLS-based build,
>> and it must be older than
>> https://gitlab.com/openconnect/openconnect/-/commit/ce8c6968f524aaa6d8387a3c63e9cdbce88f3c59.
>>
>> > VPN Log:
>>
>> What is this "VPN Log"? How was it generated? It doesn't appear to
>> contain any useful information at all.
>>
>> Dan
>>
>> ___
>> openconnect-devel mailing list
>> openconnect-devel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/openconnect-devel
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Connection problem
On Sat, Nov 20, 2021 at 1:11 AM Oleg Tyurin wrote: > > When I connect to our corporate VPN server, I do not receive all routes, so I > cannot use some resources What does "not receive all routes" mean? What routes do you *expect*, but don't get set? What happens if you try to manually add them to the routing table after connection… do they work? > The openconnect client was installed from the official freebsd repository. > The OS is 13.0-RELEASE openconnect --version output? > Please advise how can I do to fix it? > > The openconnect output is in the attached file Most of this log comes from the vpnc-script (https://gitlab.com/openconnect/vpnc-scripts/blob/master/vpnc-script), which sets up routing and DNS, not from OpenConnect itself. What version of the vpnc-script are you running? > route: writing to routing socket: Cannot allocate memory > add net 0.0.0.0: gateway 192.168.0.1 fib 0: Cannot allocate memory I've never seen errors like "cannot allocate memory" associated with routing configuration. It appears that something is going wrong with adding the VPN interface as the *default* route. I don't use or know much about *BSD's routing utilities. Have any other FreeBSD users encountered anything like this? Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Error in the push function.
On Thu, Nov 18, 2021 at 1:33 PM Amirali Hossein wrote:
> How should I resolve "Error in the push function."?
Can you give us more information? Start with the complete output of
`openconnect --version`, and what operating system you're running on.
All I can tell from the messages ("SSL connection failure" and "Failed
to obtain WebVPN cookie") is that you're using a GnuTLS-based build,
and it must be older than
https://gitlab.com/openconnect/openconnect/-/commit/ce8c6968f524aaa6d8387a3c63e9cdbce88f3c59.
> VPN Log:
What is this "VPN Log"? How was it generated? It doesn't appear to
contain any useful information at all.
Dan
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Windows 11 and UDP
On Thu, Oct 14, 2021 at 5:14 PM Shane Hird wrote: > > With UDP enabled (or not disabled) upload speeds are extremely slow. > This seems very similar to the bug mentioned by Microsoft for KB5006674 > > https://support.microsoft.com/en-us/topic/october-12-2021-kb5006674-os-build-22000-258-32255bb8-6b25-4265-934c-74fdb25f4d35 > > However I have applied this fix and the problem persists. For now I > have disabled UDP. But I believe this should be relayed to Microsoft > or perhaps third party libraries updated for openconnect?. Can anyone > else reproduce this issue? I replied on the GitLab issue you opened. https://gitlab.com/openconnect/openconnect/-/issues/330 Let's continue the discussion there. Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Issues staying connected to Pulse Secure on OpenConnect v8.10
On Mon, Jan 11, 2021 at 2:03 PM John Hannafin wrote: > Sometime last year, we noticed that at > some point between version 8.03 and 8.06, using openconnect would > become unreliable. Using 8.03, I can run the command "sudo > openconnect --juniper --protocol=nc https://[REDACTED_HOSTNAME]";, and > the VPN will stay active and work for as long as I needed it. I > noticed with version 8.06 (perhaps earlier though?), that the VPN > would run for, about 15 minutes before failing and I'd have to quit > the VPN and resign in to get another 15 minutes or so of use. This > behavior still exists in 8.10 today. I can no longer run 8.03 due to > dependencies not existing for it in Fedora 33's repos, so I'm looking > to try and solve my problem for newer versions. Any guidance or help > would be greatly appreciated. We've discovered a subtle bug in Juniper rekey/reconnection, which was introduced back in OpenConnect v8.04. Thanks to the efforts of a dedicated user who dug up this mailing list post, and was able to contribute detailed logs to help me solve this very tricky issue. See https://gitlab.com/openconnect/openconnect/-/issues/322 for the gory details. I've been able to write and test a fix for it: https://gitlab.com/openconnect/openconnect/-/merge_requests/293 It'd be helpful to have other users compile from source and test, so that we can confidently include this fix in the next release. Thanks, Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: GlobalProtect IPv6 report
On Wed, Sep 15, 2021 at 3:01 AM David Love wrote: > > I noticed this in syslog (from the Debian package of 8.10): > > Potential IPv6-related GlobalProtect config tag : > no#012This build does not support GlobalProtect IPv6 due to a lack of#012of > information on how it is configured. Please report this#012to > . > > I guess you need more information. I'm not specifically interested in > v6, but I can follow instructions if that's useful. I probably can't > get help from the server end, though. Thank you! Subsequent to the v8.10 release, we've figured out all the details of how GlobalProtect IPv6 works. So these reports are no longer needed, and we've removed all of the related "Please send us info" messages from the code for the next release. https://gitlab.com/openconnect/openconnect/-/blob/master/gpst.c -Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: OpenConnect with fortinet and multifactor authentication
Hi Ralph, On Fri, Sep 10, 2021 at 9:01 AM Ralph Serge wrote: > I came across OpenConnect while looking for a client to connect to a Fortinet > VPN server using multifactor authentication. It'd be great to have other users test our Fortinet MFA support. Currently, it *only* supports the "challenge-based" MFA mode, because that's the only one we know of that's used in the real world. See https://gitlab.com/openconnect/openconnect/-/commit/426fc3d434ae614b7e10999aff84c52dcffd047a for the implementation details. > I am using OpenConnect v.8.10 on Arch linux. > > >openconnet --version > OpenConnect version v8.10 > Using GnuTLS 3.7.2. 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, pulse You'll need to build OpenConnect from the master-branch source (see https://www.infradead.org/openconnect/building.html for instructions) in order to get support for Fortinet, as well as for a ton of other stuff we've added and improved since v8.10. Fortinet source is not yet in any released version — but at this point we're welll overdue for one. 😬 Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Available for support for F5 + MFA
On Wed, Aug 4, 2021 at 10:57 AM Antonio Petrelli wrote: > > Il giorno mer 4 ago 2021 alle ore 19:40 Antonio Petrelli > ha scritto: > > > > OMG IT WORKED! It seems that the error before happens sometimes, but > > it happens anyway sometimes because something is wrong server side. > > Wait a bit, ignore the previous email, in the next one I will post another > > log. > > I have good news and bad news. > The good news is that I managed to make it work. > The bad news is that it works only if I connect via original f5vpn, > disconnect, then launch openconnect. That's interesting. >> Probably the culprit is the access token. My guess is that when the f5vpn executable launches, it sends additional request(s) to the server to somehow activate/enable the MRHSession cookie to be used for the VPN tunnel… > GET /vdesk/get_token_for_sessid.php3 HTTP/1.0 > ... bunch of other headers ... > Cookie: LastMRH_Session=<4-bytes-hex-encoded>; TIN=66000; > MRHSession=; F5_ST=; F5_fullWT=1 > > Now a resource is going to be opened by f5vpn. The resource is: > f5-vpn://?server=&resourcename=/Common/SSL_VPN_Portal_Import-&resourcetype=network_access&cmd=launch&protocol=https&port=443&sid=&token=&otc= Can you confirm that the value of the 'sid' field in the f5-vpn:// URI precisely matches the value of the MRHSession cookie sent in the get_token_for_sessid.php3 request seen in the browser login? My expectation is YES, they should be identical. SID appears to be one of the many names used inconsistently for this 32-hex-digit value. > What to do now? Do a MITM capture of the f5vpn binary, and figure out what request(s) it sends involving the access-session-token value. > So here's the log, I hope I edited all the needed things :-D Looks good. For what it's worth, this log doesn't appear to reveal anything that we don't already understand. The part that we don't understand apparently *precedes* the requests and responses shown in the log. Thanks for working through this, and sorry for the slow response! Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Available for support for F5 + MFA
On Tue, Aug 3, 2021 at 9:08 AM Antonio Petrelli wrote: > > Hello again > From now on, the edited values are between , but the > rest is literal.ù > Ok after login, I land on a page that says "Connect to VPN". > > Clicking on it this request is sent: > > GET /vdesk/get_token_for_sessid.php3 HTTP/1.0 > Host: > User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:90.0) > Gecko/20100101 Firefox/90.0 > Accept: */* > Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3 > Accept-Encoding: gzip, deflate, br > DNT: 1 > Connection: keep-alive > Referer: > https:///vdesk/webtop.eui?webtop=/Common/Portal__Webtop&webtop_type=webtop_full > Cookie: LastMRH_Session=<4-bytes-hex-encoded>; TIN=66000; > MRHSession=; F5_ST=; F5_fullWT=1 > Sec-Fetch-Dest: empty > Sec-Fetch-Mode: cors > Sec-Fetch-Site: same-origin Since you've already arrived at the "webtop" interface, you've already completed the login process and you already have the credential (the cookie named 'MRHSession') which OpenConnect requires to be able to actually configure and connect to the VPN tunnel. I believe you should be able to simply capture the value of (using the browser dev tools), and then run OpenConnect as follows: openconnect --dump - --prot=f5 \ --cookie "MRHSession=" \ (Important: do NOT close the browser window before running this command; that may cause it to logoff the session and invalidate the cookie) I'll wager 70% odds that this Just Works. If that doesn't work, then I guess we'll have to figure out what the "token" and "access-session-token" values mean, and how they get used by the f5vpn binary. Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: Available for support for F5 + MFA
On Tue, Aug 3, 2021 at 1:22 AM Antonio Petrelli wrote: > Hello > At my firm we are using F5 and MFA from Microsoft. I noticed in the > website that, in case I have a different authentication than > username+password, it would be nice to contact you to add support for > a different authentication mechanism. Thanks! I suspect that this probably involves some kind of handoff mechanism like SAML, as we already know of for the GlobalProtect and AnyConnect protocols. > So here am I, feel free to contact me and I will try to assist you in > adding support. Can you successfully login by visiting the login page in a browser, then capturing whatever tokens result from it, and injecting those into OpenConnect? (whether in the form of a surrogate one-time-use password, or perhaps an MRHSession cookie) If so, writing an external authentication wrapper script modeled on https://github.com/dlenski/smxlogin would be a good place to start here. Dan ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
