> I'd say the problem is on the host that might not have all packages > updated, namely the ca-certificates (or equivalent) package. At a first > glance it doesn't seem like a firewall problem. > > @Vieri, please try to do a yum/apt (or equivalent depending on the > machine OS package manager) update/upgrade for at least the ca- > certificates, openssl and gnutls packages and try again.
Only problem is the OS in question doesn't have a package management :-) Did you see this line: * CAfile: C:\cURL\curl-ca-bundle.crt Beside that, one thing to keep in mind here is that only using the same IP address doesn't really mean the request has to come from the same server. Regards, Simon > > My 2 cents. > Best regards. > > On Mon, 2022-02-28 at 11:39 +0100, Matt Darfeuille wrote: >> On 2/28/2022 11:22 AM, Vieri Di Paola wrote: >> > Hi, >> > >> > Some hosts in the LAN are randomly unable to connect to external >> > https >> > services. All conections are going through a Shorewall routing >> > firewall. >> > >> > One host in the same vlan with src IP addr. 10.215.111.210 is >> > properly >> > accessing the following site: >> > >> > curl --verbose --head https://teams.microsoft.com >> > * Trying 52.113.194.132:443... >> > * Connected to teams.microsoft.com (52.113.194.132) port 443 (#0) >> > * ALPN, offering h2 >> > * ALPN, offering http/1.1 >> > * CAfile: C:\cURL\curl-ca-bundle.crt >> > * CApath: none >> > * TLSv1.0 (OUT), TLS header, Certificate Status (22): >> > * TLSv1.3 (OUT), TLS handshake, Client hello (1): >> > * TLSv1.2 (IN), TLS header, Certificate Status (22): >> > * TLSv1.3 (IN), TLS handshake, Server hello (2): >> > * TLSv1.2 (IN), TLS handshake, Certificate (11): >> > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): >> > * TLSv1.2 (IN), TLS handshake, Server finished (14): >> > * TLSv1.2 (OUT), TLS header, Certificate Status (22): >> > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): >> > * TLSv1.2 (OUT), TLS header, Finished (20): >> > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): >> > * TLSv1.2 (OUT), TLS header, Certificate Status (22): >> > * TLSv1.2 (OUT), TLS handshake, Finished (20): >> > * TLSv1.2 (IN), TLS header, Finished (20): >> > * TLSv1.2 (IN), TLS header, Certificate Status (22): >> > * TLSv1.2 (IN), TLS handshake, Finished (20): >> > * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 >> > * ALPN, server accepted to use h2 >> > [etc] >> > >> > Another host in the same vlan with IP addr. 10.215.111.199 is >> > unable >> > to connect to the exact same site and at the same time >> > (52.113.194.132): >> > >> > curl --verbose --head https://teams.microsoft.com >> > * Trying 52.113.194.132:443... >> > * Connected to teams.microsoft.com (52.113.194.132) port 443 (#0) >> > * ALPN, offering h2 >> > * ALPN, offering http/1.1 >> > * CAfile: C:\curl\curl-ca-bundle.crt >> > * CApath: none >> > * TLSv1.0 (OUT), TLS header, Certificate Status (22): >> > * TLSv1.3 (OUT), TLS handshake, Client hello (1): >> > * TLSv1.0 (OUT), TLS header, Unknown (21): >> > * TLSv1.3 (OUT), TLS alert, decode error (562): >> > * error:0A000126:SSL routines::unexpected eof while reading >> > * Closing connection 0 >> > curl: (35) error:0A000126:SSL routines::unexpected eof while >> > reading >> > >> > This is what I see with tcpdump while trying the above connection >> > ("wan" is the interface facing Internet): >> > >> > # tcpdump -n -i wan host 10.215.111.199 >> > dropped privs to pcap >> > tcpdump: verbose output suppressed, use -v[v]... for full protocol >> > decode >> > listening on wan, link-type EN10MB (Ethernet), snapshot length >> > 262144 bytes >> > 10:58:55.602587 IP 10.215.111.199.60258 > 52.113.194.132.443: Flags >> > [S], seq 1097095637, win 64240, options [mss 1460,nop,wscale >> > 8,nop,nop,sackOK], length 0 >> > 10:58:55.602797 IP 52.113.194.132.443 > 10.215.111.199.60258: Flags >> > [S.], seq 2635751257, ack 1097095638, win 14600, options [mss >> > 1460,nop,nop,sackOK,nop,wscale 7], length 0 >> > 10:58:55.604900 IP 10.215.111.199.60258 > 52.113.194.132.443: Flags >> > [.], ack 1, win 1026, length 0 >> > 10:58:55.880427 IP 10.215.111.199.60258 > 52.113.194.132.443: Flags >> > [P.], seq 1:518, ack 1, win 1026, length 517 >> > 10:58:55.880581 IP 52.113.194.132.443 > 10.215.111.199.60258: Flags >> > [.], ack 518, win 123, length 0 >> > >> > What makes things "worse" is that if I tamper with this host's >> > "hosts" >> > file and manually set the name resolution of teams.microsoft.com to >> > 52.113.195.132 (another valid IP addr. for teams.microsoft.com) >> > then >> > it can finally connect as expected. >> > >> > There's no shorewall rule to block 52.113.194.132:443 so I don't >> > know >> > why the TLS handshake is failing. >> > >> > I'd like to determine if this is a communications issue (ie. >> > Shorewall) or a client/server hosts problem. >> > >> >> I'm not sure that this is the issue, but Teams requires lots of open >> ports to work. >> I had to open those for the Desktop edition. >> > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
