Hi again David, I am currently in the office where the procedure to connect to the VPN is slightly different (because the head end is on the same network as the VPN gateway), so I'm going to wait until I'm home again before doing the --dump-http-traffic tests. However, after thinking more about the problem, I realized something interesting. When on xubuntu at home and connecting to the VPN for the first time, I get a warning on the command line that the certificate has problems, and I can enter 'yes' to add an exception and continue the connection. I never got this warning in the crouton chroot. I tried connecting to the VPN in a fresh Ubuntu chroot with the --servercert XXXXX option, and got the following: Server certificate verify failed: signer not found Server SSL certificate didn't match: sha256:[LALALACANTHEARYOU] SSL connection failure: Error in the certificate. Unlike examples of that option I found on the Internet, openconnect did not suggest that I use that fingerprint to connect. Nevertheless, I tried connecting with sudo openconnect -v --servercert sha256:[LALALACANTHEARYOU] [etc], and saw these lines several times in the output: SSL negotiation with noaaguestvpn.ncep.noaa.gov Server certificate verify failed: signer not found Connected to HTTPS on noaaguestvpn.ncep.noaa.gov The SSH connection to the head end seemed successfully made, but again, no traffic whatsoever in the tunnel. I wonder if ChromeOS upgraded security in v77, and that is doing something to block the traffic. Is there a way through openconnect (or in general) to work around this? Thanks! Adam On Mon, Dec 16, 2019 at 11:17 AM Adam Allgood <avram.meir@xxxxxxxxx> wrote: > > 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
