On Mon, 2019-12-16 at 15:08 -0500, Adam Allgood wrote: > 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. Perhaps the server is in a round-robin DNS and you really are getting different servers (hence difference certificate fingerprints) every time. You'd do better to *fix* the certificate problem. Can't you install the appropriate SSL CA so that they're properly trusted? > 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 Right. If the verification fails, it still reports that but if you have the *matching* --servercert fingerprint on the command line then it'll make an exception and allow the connection to continue anyway. > 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? Or maybe it's something going wrong with the routing setup. Maybe your *outbound* packets aren't actually reaching the VPN server? Or the inbound packets on the public network are being firewalled locally and not reaching openconnect? Can you get a packet capture on your local network to correlate with a DTLS send/receive debug log like the ones you showed before? And can you show the output of 'ip route' before and after connecting?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
