For the past few weeks, I've been having trouble connecting to yahoo mail. Does anyone know what could be the problem?
I try this with HE IPv6 tunnel. Nothing happens except a timeout after five minutes.
$ curl --verbose --verbose https://mail.yahoo.com
* Rebuilt URL to: https://mail.yahoo.com/
* Trying 2001:4998:1c:800::1000...
* TCP_NODELAY set
* Connected to mail.yahoo.com (2001:4998:1c:800::1000) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* Operation timed out after 300156 milliseconds with 0 out of 0 bytes received
* stopped the pause stream!
* Closing connection 0
curl: (28) Operation timed out after 300156 milliseconds with 0 out of 0 bytes received
whereas if I do:
$ curl --verbose --verbose -4 https://mail.yahoo.com
the response is instantaneous.
A plain http://mail.yahoo.com over IPv6 (port 80) forwards immediately to https://mail.yahoo.com (port 443) which times out. So http to yahoo over IPv6 is good.
I can get to other IPv6 sites just fine, he.net, youtube, google... with and without https. ipv6foo on my browser verifies IPv6 connection usage. I'm filling out this form with https://forums.he.net (port 443) and the site is quite responsive.
I've reproduced this problem on Windows, RHEL and Ubuntu.
I'm running into the same problem. If I take the IPv6 tunnel down I have no problems.
This only started recently.
I added Yahoo's IPv6 block to my firewall's IPv6 block list (used to block Netflix's networks so I can watch videos on Netflix) and it's working now. There's an issue between HE and Yahoo that still needs to be resolved but this works in the meantime.
Yahoo's IPv6 network is 2001:4998::/32.
Are they using Cogent for transit?
No. I can see three routes to them (AS10310), one through NetAssist (AS29632) and two through HE (AS6939).
This could be an issue with PMTU discovery. Please check your MTU setting on both tunnel ends and if needed - lower it to match your physical interface MTU minus IPv4 header.
The MTU on the tunnel is 1480 and the MTU of the physical interface is 1500.
I just removed the 2001:4998::/32 from my firewall's IPv6 block list and can get to Yahoo Mail now. So whatever was causing the issue appears to have been fixed in the past 12 days.
Quote from: dittman on December 10, 2020, 09:29:59 PM
I just removed the 2001:4998::/32 from my firewall's IPv6 block list and can get to Yahoo Mail now. So whatever was causing the issue appears to have been fixed in the past 12 days.
And the issue is back.
Same here. Is there a way to open a trouble ticket with HE? They might be in a position to help get the routing or whatever corrected.
As of yesterday, I'm seeing this also, but only from my Windows 10 laptop. My iPad gets there fine. Strange. Maybe a record caching issue?
I have been seeing this same issue as well for about 2 months. Adding Yahoo's IP range to my outbound blocklist fixed it. Connected via Ashburn server.
Quote from: dittman on November 28, 2020, 05:42:32 PM
I added Yahoo's IPv6 block to my firewall's IPv6 block list (used to block Netflix's networks so I can watch videos on Netflix) and it's working now. There's an issue between HE and Yahoo that still needs to be resolved but this works in the meantime.
Yahoo's IPv6 network is 2001:4998::/32.
From submitted tickets and internal tests, MTR/ping/traces show that packets are delivered to Yahoo nodes without loss. Native IPv6 is connecting without issue to service ports at the destination. Over tunneled connections, MTR works, however Yahoo is not responding at the service level regardless of MTU tuning. I've sent them an email detailing this, but since packets are clearly being delivered to their network, they've likely got some issues to sort out on their side.
If their users haven't already, I recommend also contacting them directly since this appears to be an issue with their service and not us delivering packets over the network.
Quote from: broquea on January 04, 2021, 04:52:01 PM
From submitted tickets and internal tests, MTR/ping/traces show that packets are delivered to Yahoo nodes without loss. Native IPv6 is connecting without issue to service ports at the destination. Over tunneled connections, MTR works, however Yahoo is not responding at the service level regardless of MTU tuning. I've sent them an email detailing this, but since packets are clearly being delivered to their network, they've likely got some issues to sort out on their side.
If their users haven't already, I recommend also contacting them directly since this appears to be an issue with their service and not us delivering packets over the network.
I haven't had a problem with Yahoo lately, so perhaps they found the issue and have fixed it.
Quote from: dittman on January 15, 2021, 07:20:25 PM
Quote from: broquea on January 04, 2021, 04:52:01 PM
From submitted tickets and internal tests, MTR/ping/traces show that packets are delivered to Yahoo nodes without loss. Native IPv6 is connecting without issue to service ports at the destination. Over tunneled connections, MTR works, however Yahoo is not responding at the service level regardless of MTU tuning. I've sent them an email detailing this, but since packets are clearly being delivered to their network, they've likely got some issues to sort out on their side.
If their users haven't already, I recommend also contacting them directly since this appears to be an issue with their service and not us delivering packets over the network.
I haven't had a problem with Yahoo lately, so perhaps they found the issue and have fixed it.
I cannot connect to any Yahoo services over the HE tunnel for secure TCP on port 443 (https://www.yahoo.com, https://finance.yahoo.com). It seems like HE is blocking that traffic to Yahoo. My firewall isn't blocking the traffic, I have disabled IDS. I have an allow rule for all IPv4 and IPv6 traffic from the LAN to WAN and WANv6 for all ports and protocols. I have no entries of the traffic being blocked by my firewall. I have a 1480 MTU on the tunnel and my adapter interface is 1500. I can ping6 and traceroute6 the yahoo servers and I get echo replies and there is a route to the servers, but when I try to execute an HTTPS GET, the traffic is blocked.
I get a timeout for an https curl:
curl --verbose --verbose https://finance.yahoo.com
* Trying 2001:4998:60:800::1106...
* TCP_NODELAY set
* Connected to finance.yahoo.com (2001:4998:60:800::1106) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Operation timed out after 300341 milliseconds with 0 out of 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 300341 milliseconds with 0 out of 0 bytes receivedHowever for http, I get a response which is an https redirect:
curl --verbose --verbose http://finance.yahoo.com
* Trying 2001:4998:60:800::1105...
* TCP_NODELAY set
* Connected to finance.yahoo.com (2001:4998:60:800::1105) port 80 (#0)
> GET / HTTP/1.1
> Host: finance.yahoo.com
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Sat, 30 Jan 2021 00:01:17 GMT
< Server: ATS
< Cache-Control: no-store
< Content-Type: text/html
< Content-Language: en
< Content-Security-Policy: frame-ancestors 'self' https://*.techcrunch.com https://*.yahoo.com https://*.aol.com https://*.huffingtonpost.com https://*.oath.com https://*.search.yahoo.com https://*.search.aol.com https://*.search.huffpost.com https://*.verizonmedia.com https://*.publishing.oath.com https://*.autoblog.com; sandbox allow-forms allow-same-origin allow-scripts allow-popups allow-popups-to-escape-sandbox allow-presentation; report-uri https://csp.yahoo.com/beacon/csp?src=ats&site=finance®ion=US&lang=en-US&device=desktop&yrid=5e5vlcdg198ed&partner=;
< Location: https://finance.yahoo.com/
< Content-Length: 8
< Referrer-Policy: no-referrer-when-downgrade
< Age: 0
< Connection: keep-alive
<
* Connection #0 to host finance.yahoo.com left intact
redirect* Closing connection 0Doing it over IPv4 works just fine:
curl --verbose --verbose -4 https://finance.yahoo.com
* Trying 69.147.92.11...
* TCP_NODELAY set
* Connected to finance.yahoo.com (69.147.92.11) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (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 handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=Sunnyvale; O=Oath Inc; CN=*.yahoo.com
* start date: Jan 14 00:00:00 2021 GMT
* expire date: Mar 2 23:59:59 2021 GMT
* subjectAltName: host "finance.yahoo.com" matched cert's "*.yahoo.com"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fe33c00d600)
> GET / HTTP/2
> Host: finance.yahoo.com
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< referrer-policy: no-referrer-when-downgrade
< strict-transport-security: max-age=15552000
< x-frame-options: SAMEORIGIN
< content-security-policy: sandbox allow-downloads allow-forms allow-modals allow-same-origin allow-scripts allow-popups allow-popups-to-escape-sandbox allow-top-navigation-by-user-activation allow-presentation; report-uri https://csp.yahoo.com/beacon/csp?src=yahoofinance; report-to csp-endpoint;
< report-to: {"group":"csp-endpoint","max-age":10886400,"endpoints":[{"url":"https://csp.yahoo.com/beacon/csp?src=yahoofinance"}]}
< content-type: text/html; charset=utf-8
< set-cookie: B=9723i9tg198op&b=3&s=uo; expires=Sat, 30-Jan-2022 00:06:49 GMT; path=/; domain=.yahoo.com
< date: Sat, 30 Jan 2021 00:06:49 GMT
< server: ATS
< cache-control: max-age=0, private
< expires: -1
< age: 0
< expect-ct: max-age=31536000, report-uri="http://csp.yahoo.com/beacon/csp?src=yahoocom-expect-ct-report-only"
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
...............
Quote from: dittman on January 15, 2021, 07:20:25 PM
Quote from: broquea on January 04, 2021, 04:52:01 PM
From submitted tickets and internal tests, MTR/ping/traces show that packets are delivered to Yahoo nodes without loss. Native IPv6 is connecting without issue to service ports at the destination. Over tunneled connections, MTR works, however Yahoo is not responding at the service level regardless of MTU tuning. I've sent them an email detailing this, but since packets are clearly being delivered to their network, they've likely got some issues to sort out on their side.
If their users haven't already, I recommend also contacting them directly since this appears to be an issue with their service and not us delivering packets over the network.
I haven't had a problem with Yahoo lately, so perhaps they found the issue and have fixed it.
The problem is back for me as well. I can ping, I just can't connect to any of their services.
The issue still persists. :-(
I use Yahoo Finance and my firewall rule is to reject connections to 2a00:1288:80::/48.
I just submit a request to he support and yahoo support, provided tracepath result and explain it to both ends. I am hoping someone from HE or Yahoo will take a look on it. I will suggest others to do the same.
E
I have the same issue with Yahoo via the HE tunnel with my own IPv6 prefix via a BGP session with HE
Doing the same test curl --verbose --verbose https://mail.yahoo.com
I don't have such this issue, if I run this test from a server with its IPv6 not going through this tunnel.
Difficult also to find a Yahoo support to assist.
He support is answering but with no solution
I could test more the Yahoo issue with HE IPv6 tunnel.
My SIT tunnel uses MTU 1480
For Yahoo access, if I change the MTU of my server or computer to MTU from 1500 to 1480, it works fine, otherwise no.
It seems that PMTU with Yahoo is not well negociated.
What else could be done?
Eric
Hi,
my MTU is set to 1480 already. I still can't get to https://finance.yahoo.com/ Can you try it from your end?
Thanks,
E
Quote from: hellokitty2016 on April 05, 2021, 08:09:10 AM
my MTU is set to 1480 already. I still can't get to https://finance.yahoo.com/ Can you try it from your end?
Tried setting it to 1280?
I tried lower the MTU. Anyways, I am able to get to finance.yahoo.com via IPv6.. Can other tries it and report back as well?
I am seeing the same issue with e-mail.
With Thunderbird and Firefox, a workaround is to set:
network.dns.ipv4OnlyDomains
to
yahoo.com,yahooapis.com,mail.yahoo.com,login.yahoo.net
in the configuration editor (Tools->options->general-> "advanced config"; about:config respectively). Of course, if you already have domains in this list, just append these.
This will force the DNS lookups for these domains to request only IPv4 addresses, while continuing to use IPv6 elsewhere. (Assuming you aren't on an IPv6-only machine...)
I don't use other Yahoo! services, but if you do, you may have to add more domains to the list.
Getting Yahoo! (and other large domains) to fix things like this is extremely difficult to impossible. They have so many layers of useless "virtual assistant", script-limited humans, and other barriers that finding a technically savvy human is an exercise in frustration.
Hopefully, at some point this will percolate up to someone who'll fix it. Maybe the latest new owners will help. Hope springs eternal.
IPv6 Yahoo access only works for me when I set MTU on the tunnel to 1280.