I saw this Faravahar votes on thousands of relays as not running (#79) · Issues · The Tor Project / Network Health / Analysis · GitLab and actually our relays (menhera1 and menhera1b) here at AS63806 are marked as not running by the dirauth faravahar. (Consensus health and Consensus health)

I report that from our relays’ IP address (43.228.174.250), 216.218.219.41:443 is reachable when we use an ephemeral port on our side to connect to faravahar via TCP.

ubuntu@tor-relay:~$ curl -vk https://216.218.219.41
*   Trying 216.218.219.41:443...
* Connected to 216.218.219.41 (216.218.219.41) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* 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 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=www.j6nqhase3dust.net
*  start date: May  8 00:00:00 2024 GMT
*  expire date: Sep 18 23:59:59 2024 GMT
*  issuer: CN=www.23o5rzsiy7.com
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/1.1
> Host: 216.218.219.41
> User-Agent: curl/7.81.0
> Accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing

Which indicates no routing-level issues such as BGP. (On AS63806’s Looking Glass nothing strange appears, as follows)

Also, I can connect to faravahar from port 9001 on other machines on the same network, although we cannot test on 43.228.174.250 because the relays are running:

curl -vk --local-port 9001 https://216.218.219.41/

Any ideas?

Yuka MORI via Tor Project Forum:

I saw this Faravahar votes on thousands of relays as not running (#79) · Issues · The Tor Project / Network Health / Analysis · GitLab and actually our relays (menhera1 and menhera1b) here at AS63806 are marked as not running by the dirauth faravahar. (Consensus health and Consensus health)

I report that from our relays’ IP address (43.228.174.250), 216.218.219.41:443 is reachable when we use an ephemeral port on our side to connect to faravahar via TCP.

ubuntu@tor-relay:~$ curl -vk https://216.218.219.41
*   Trying 216.218.219.41:443...
* Connected to 216.218.219.41 (216.218.219.41) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* 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 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=www.j6nqhase3dust.net
*  start date: May  8 00:00:00 2024 GMT
*  expire date: Sep 18 23:59:59 2024 GMT
*  issuer: CN=www.23o5rzsiy7.com
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/1.1
> Host: 216.218.219.41
> User-Agent: curl/7.81.0
> Accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing

Which indicates no routing-level issues such as BGP. (On AS63806’s Looking Glass nothing strange appears, as follows)

Also, I can connect to faravahar from port 9001 on other machines on the same network, although we cannot test on 43.228.174.250 because the relays are running:

curl -vk --local-port 9001 https://216.218.219.41/

Any ideas?

Yes. There is one at least over in
Gitlab:
Might be IPv6 related.

1 Like