Hi David, Thanks for continuing to look into this! I recently discovered something interesting. I put a new hard drive into my wife's old HP desktop that had been lying around for a year and installed Xubuntu. I then set up smartcard services (e.g., pcscd, CACkey), gnuTLS, and openconnect, and voila! I connected to the office VPN and traffic passed back and forth as normal. So it seems that the problem may be with ChromeOS, and maybe some new security setting after the v77 update in September is blocking the traffic. Your theory about a captive portal or privacy notice is interesting, because I get security warnings about invalid certificates from the captive portal when trying to connect to the building WiFi when I'm physically in the office (but I can force Chrome to proceed anyway and connect), and perhaps something similar is causing Chrome to block the VPN traffic when connecting to my office IT infrastructure from home. If I ran openconnect with --dump-http-traffic from my successful Xubuntu session at home, and also from my unsuccessful ChromeOS Ubuntu chroot, would that be helpful? Thanks! Adam On Mon, Dec 16, 2019 at 7:37 AM David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > > On Tue, 2019-11-05 at 13:32 -0600, Daniel Lenski wrote: > > On Fri, Nov 1, 2019 at 3:58 PM Adam Allgood <avram.meir@xxxxxxxxx> wrote: > > > > > > Hello again Dan, sorry for the delayed response. > > > > > > On Thu, Oct 24, 2019 at 2:46 PM Daniel Lenski <dlenski@xxxxxxxxx> wrote: > > > > > > > > Interesting. Even in your more verbose log, it appears that > > > > OpenConnect is totally and entirely failing to receive any response > > > > over the DTLS channel… except for the MTU DPD probe at the beginning. > > > > > > > > This is why I suggest upgrading to a more recent version in which > > > > David Woodhouse has made the DTLS MTU detection much more robust and… > > > > > > > > > > I updated to: > > > > > > OpenConnect version v8.05 > > > Using GnuTLS. Features present: PKCS#11, HOTP software token, TOTP > > > software token, System keys, DTLS, ESP > > > Supported protocols: anyconnect (default), nc, gp, pulse > > > > > > Unfortunately I appear to be having the same problems. > > > > I'm kind of stumped here. > > > > It appears that the symptoms with DTLS enabled, and without DTLS, are > > pretty much identical: you receive *no incoming packets* from the VPN > > tunnel of any kind. Not even DPD responses. > > > > That suggests this is an issue with the basic protocol used by the > > client and server to communicate with each other, and not something at > > the network level (say, a misconfigured firewall). > > > > You mentioned that other users with *older* versions of OpenConnect > > can successfully connect and send traffic…? Exactly which versions of > > OpenConnect, and which OSes are they using? Can you test if your > > account works on one of their laptops? > > Hm, try --no-xmlpost maybe? Although that would be *very* old... > > > If we can figure this out by determining what the older clients are > > doing to successfully connect, great. If not, we'll probably need a > > MITM dump to figure out what's new/different about your VPN. > > I think we've seen other reports of a privacy notice or something which > needs accepting before you can actually pass traffic. Seems like you're > on a captive portal when you join the VPN, until you accept the terms. > > A MITM capture from an actual AnyConnect client would be very > enlightening. Or if MITM is hard, the full log with --dump-http-traffic > as OpenConnect connects, and then we can point an AnyConnect client at > an ocserv server hacked to present the same stimuli. _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
