Re: VPN seems to connect but fails to get a response from the peer

2019-12-17 Thread Adam Allgood 
On Tue, Dec 17, 2019 at 5:24 AM David Woodhouse  wrote:
>
> 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?

I will put in a ticket with my IT networking folks, but unfortunately
they are beyond swamped and this issue will likely be extremely low
priority for them since the majority of users can access the VPN with
no problems.

> 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?
>

I connected while running sudo tcpdump -i any, which produced a
humongous file. Here is a sample of the output (trying to find where
the connection to the VPN is made):

22:32:51.058707 IP localhost.30011 > localhost.43934: Flags [P.], seq
6565:6577, ack 15694, win 350, options [nop,nop,TS val 32971139 ecr
32971139], length 12
22:32:51.094305 IP localhost.43934 > localhost.30011: Flags [P.], seq
15694:15722, ack 6577, win 3635, options [nop,nop,TS val 32971175 ecr
32971139], length 28
22:32:51.094520 IP localhost.30011 > localhost.43934: Flags [P.], seq
6577:6589, ack 15722, win 350, options [nop,nop,TS val 32971175 ecr
32971175], length 12
22:32:51.130243 IP localhost.43934 > localhost.30011: Flags [P.], seq
15722:15750, ack 6589, win 3635, options [nop,nop,TS val 32971211 ecr
32971175], length 28
22:32:51.130456 IP localhost.30011 > localhost.43934: Flags [P.], seq
6589:6601, ack 15750, win 350, options [nop,nop,TS val 32971211 ecr
32971211], length 12
22:32:51.166144 IP localhost.43934 > localhost.30011: Flags [P.], seq
15750:15778, ack 6601, win 3635, options [nop,nop,TS val 32971247 ecr
32971211], length 28
22:32:51.166362 IP localhost.30011 > localhost.43934: Flags [P.], seq
6601:6613, ack 15778, win 350, options [nop,nop,TS val 32971247 ecr
32971247], length 12
22:32:51.201903 IP localhost.43934 > localhost.30011: Flags [P.], seq
15778:15806, ack 6613, win 3635, options [nop,nop,TS val 32971282 ecr
32971247], length 28
22:32:51.205718 IP localhost.30011 > localhost.43934: Flags [P.], seq
6613:6625, ack 15806, win 350, options [nop,nop,TS val 32971286 ecr
32971282], length 12
22:32:51.223364 IP localhost.43934 > localhost.30011: Flags [P.], seq
15806:15834, ack 6625, win 3635, options [nop,nop,TS val 32971304 ecr
32971286], length 28
22:32:51.223599 IP localhost.30011 > localhost.43934: Flags [P.], seq
6625:6637, ack 15834, win 350, options [nop,nop,TS val 32971304 ecr
32971304], length 12
22:32:51.259141 IP localhost.43934 > localhost.30011: Flags [P.], seq
15834:15862, ack 6637, win 3635, options [nop,nop,TS val 32971340 ecr
32971304], length 28
22:32:51.259406 IP localhost.30011 > localhost.43934: Flags [P.], seq
6637:6649, ack 15862, win 350, options [nop,nop,TS val 32971340 ecr
32971340], length 12
22:32:51.294607 IP localhost.43934 > localhost.30011: Flags [P.], seq
15862:15890, ack 6649, win 3635, options [nop,nop,TS val 32971375 ecr
32971340], length 28
22:32:51.294820 IP localhost.30011 > localhost.43934: Flags [P.], seq
6649:6661, ack 15890, win 350, options [nop,nop,TS val 32971375 ecr
32971375], length 12
22:32:51.316029 IP6 :: > ff02::16: HBH ICMP6, multicast listener
report v2, 1 group record(s), length 28
22:32:51.329336 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, length 141
22:32:51.329363 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, length 221
22:32:51.329380 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, length 301
22:32:51.329396 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, length 381
22:32:51.329413 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, length 461
22:32:51.329430 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, length 541
22:32:51.329447 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, length 621
22:32:51.329465 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, length 701
22:32:51.329483 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, length 781
22:32:51.329502 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, length 861
22:32:51.329521 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, length 941
22:32:51.329541 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, length 1021
22:32:51.329561 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, length 1101
22:32:51.329581 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, length 1181
22:32:51.329602 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, length 1261
22:32:51.329623 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, length 1341
22:32:51.329647 IP 192.168.1.197.41287 > 140.90.73.186.443: UDP, bad
length 1421 > 1376

Re: VPN seems to connect but fails to get a response from the peer

2019-12-17 Thread David Woodhouse 
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 X 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?



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel