Print

[KNBu5ZMdbR]

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.

Code: [Select]

$ 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:

Code: [Select]

$ curl --verbose --verbose -4 https://mail.yahoo.comthe 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.

[dittman]

I'm running into the same problem.  If I take the IPv6 tunnel down I have no problems.

This only started recently.

[dittman]

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.

[kriteknetworks]

Are they using Cogent for transit?

[tomkep]

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.

[dittman]

The MTU on the tunnel is 1480 and the MTU of the physical interface is 1500.

[dittman]

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.

[dittman]

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.

[KNBu5ZMdbR]

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.

[snarked]

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?

[justinowens]

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.

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.

[broquea]

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.

[dittman]

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.

[JBDynamics]

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:

Code: [Select]

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 received
However for http, I get a response which is an https redirect:

Code: [Select]

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&region=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 0
Doing it over IPv4 works just fine:

Code: [Select]

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


[dittman]

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.