Cannot connect to https://bugzilla.opensuse.org via IPv6

English Network/Internet
1

Since some weeks ago (months?) I could not get the newsfeed from news.opensuse.org, but I did not give this much thought. Yesterday, during a YaST Online Update, I was curious about a bugzilla entry. I clicked on the link, but could not connect. I could not even connect via the url https://bugzilla.opensuse.org:

Firefox 35.0 reports: The connection was reset
Konqueror 4.14.4 reports: SSL negotiation failed
Chromium 39.0.2171.65 reports: Error code: ERR_CONNECTION_RESET

A bit of research in the console:

Get the IPv4 address:

> dig bugzilla.opensuse.org a | egrep -v '^(;|$)'
bugzilla.opensuse.org.  260     IN      CNAME   www.opensuse.org.
www.opensuse.org.       260     IN      A       130.57.66.6

Connect via IPv4 (succeeds):

> openssl s_client -connect 130.57.66.6:443 -state -servername bugzilla.opensuse.org -quiet <<<$'.
.'
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
verify return:1
depth=0 C = US, L = Provo, ST = Utah, O = "Novell, Inc.", CN = *.opensuse.org
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
read:errno=0
SSL3 alert write:warning:close notify

Get the IPv6 address:

> dig bugzilla.opensuse.org aaaa | egrep -v '^(;|$)'
bugzilla.opensuse.org.  259     IN      CNAME   www.opensuse.org.
www.opensuse.org.       600     IN      AAAA    2620:113:8044:66:130:57:66:6

Connect via IPv6 (fails):

> openssl s_client -connect '[2620:113:8044:66:130:57:66:6]:443' -state -servername bugzilla.opensuse.org
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 291 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

I have this problem with other sites too like news.opensuse.org, www.opensuse.org and forums.opensuse.org. I could only login to forums.opensuse.org by setting network.dns.disableIPv6 to true in Firefox. Using network.dns.ipv4OnlyDomains also works, but these are work-arounds, not solutions.

Firefox seems smart enough to fall back to IPv4 (www.opensuse.org), but not always (e.g. bugzilla).

So in short:

  • the server is reachable via IPv4 and IPv6
  • the webserver is reachable on port 443 via IPv4 but not via IPv6

Could somebody please confirm?

Kind regards,

Leen

2

IPv6 to bugzilla is fine here. But IPv6 to forums.opensuse.org fails to connect.

I can use forums with firefox, but not with rekonq or konqueror. It seems that rekonq and konqueror don’t fail over to IPv4. Also firefox caches information, so that after the first try it will directly use IPv4 in future connection.

I’m actually using “rekonq” for this. What I did was add a line to “/etc/hosts”


130.57.66.6     forums.opensuse.org

Since the hosts file is preferred over DNS, rekonq and konqueror now only try IPv4 connections to forums.opensuse.org. Presumably a similar work-around will work for you to contact bugzilla.

There may be a routing problem somewhere causing your difficulty. Whether the routing problem is at your ISP or at the destination is hard to determine.

3

Thanks for your reaction, nrickert. It looks like I am not the only one :-).

BTW, I realized too late that I did not ask exactly what to confirm, so: what output do you get when you execute the next line in a console:

openssl s_client -connect '[2620:113:8044:66:130:57:66:6]:443' -state -servername bugzilla.opensuse.org

Kind regards,

Leen

4

The terminal session is still open, so I am just scrolling back and giving you my output from when I originally tried that:


% openssl s_client -connect '[2620:113:8044:66:130:57:66:6]:443' -state -servername bugzilla.opensuse.org
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
verify return:1
depth=0 C = US, L = Provo, ST = Utah, O = "Novell, Inc.", CN = *.opensuse.org
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
---
Certificate chain
 0 s:/C=US/L=Provo/ST=Utah/O=Novell, Inc./CN=*.opensuse.org
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFQzCCBCugAwIBAgIQDWJqtx4/GFYfXkW0IAS1dTANBgkqhkiG9w0BAQsFADBw
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz
dXJhbmNlIFNlcnZlciBDQTAeFw0xNTAyMTcwMDAwMDBaFw0xODA0MjMxMjAwMDBa
MFwxCzAJBgNVBAYTAlVTMQ4wDAYDVQQHEwVQcm92bzENMAsGA1UECBMEVXRhaDEV
MBMGA1UEChMMTm92ZWxsLCBJbmMuMRcwFQYDVQQDDA4qLm9wZW5zdXNlLm9yZzCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM07oOJm4XLz3IrTq3W5rUgv
RYGLiZ/xjzG9Vw5fm8eZdH10UAMf9gbGB6dHUOqx56A34yodVeTMHYsMHBW+uqLk
TZk8sJSsHYeSxxq0nkiqyFKoVWCYs5u99B3mKM82BBpKDiQZPdKTq5vpfHgQWne+
CdpH6aqIhGRgAz/My9IVIS4Bm6vW/umCeyzZxO5TytZBZi+l8dM50iEBmsg8+B1g
rRJvm1haF8G8JNnKf/KTGTEA30erQ3Zbxf7VwaQUBXqxSuW25aim0FwTRoX41g3i
FQVibB2kiz5D+brPXzVzqJCXLtMLeyJZFPnFhzSgoeo/YdhlH3p1J5VRi+cGUVcC
AwEAAaOCAeswggHnMB8GA1UdIwQYMBaAFFFo/5CvAgd1PMzZZWRiohK4WXI7MB0G
A1UdDgQWBBT5haE+0409kBfZi6Hq8xwd9nWDvDAnBgNVHREEIDAegg4qLm9wZW5z
dXNlLm9yZ4IMb3BlbnN1c2Uub3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAU
BggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0fBG4wbDA0oDKgMIYuaHR0cDovL2Ny
bDMuZGlnaWNlcnQuY29tL3NoYTItaGEtc2VydmVyLWczLmNybDA0oDKgMIYuaHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTItaGEtc2VydmVyLWczLmNybDBCBgNV
HSAEOzA5MDcGCWCGSAGG/WwBATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5k
aWdpY2VydC5jb20vQ1BTMIGDBggrBgEFBQcBAQR3MHUwJAYIKwYBBQUHMAGGGGh0
dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBNBggrBgEFBQcwAoZBaHR0cDovL2NhY2Vy
dHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkhpZ2hBc3N1cmFuY2VTZXJ2ZXJD
QS5jcnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAQEAF+txhotR6kMJ
c/gRDAVCcc0Zj5cw5cuGeg7g3vG5Je45upbTfKQ/n2uU2AR0VIsap0Q8Zmo0/i/K
YVaq43HCdjB6mXz4KKl8IRbFT1WN5sI+HpXpAaWJ53KF3EkQj9w0NIR5QPvFWG8X
5zmg/SbyLdEuSQqtbOIm9KPwEAXo7+LDbiFAxMgbtAuKRUOuCWyRF/zeBjJSKX4E
NUB9stQUT+27GNZZNlyFTtmHQJUoIOy/hflAUQIGoXJdC2cWbVgl/ih5pjhwdVGi
BCv1oMDduoSF/wqtII/TTosjCK3YVZv1H3exAmtboMCZ1PAIOrMtQZZZrBoudiII
bpWKe/in7g==
-----END CERTIFICATE-----
subject=/C=US/L=Provo/ST=Utah/O=Novell, Inc./CN=*.opensuse.org
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
---
No client certificate CA names sent
---
SSL handshake has read 2764 bytes and written 649 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-SHA256
    Session-ID: A42BC6668D550BBA899B5BCC56613097A58EA99AC44CCC83C9876240F1999ECB
    Session-ID-ctx: 
    Master-Key: 0A24D2BC6F3E5063395089A1A2353ED4B083A7A3BD828D0A3D0A8961665E39442D4D964E8015CE1E22A73B3ED8EDFE19
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1424959372
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

QUIT
DONE
SSL3 alert write:warning:close notify
5

Thanks, nrickert, much appreciated. That was jaw-dropping. :wink:

I executed the same command at my router, and got the same result as you did. So the problem is on my end and I will investigate.

Kind regards,

Leen

6

To me it looks that this question might be worthwhile to post in the Forums Feedback > How to use the Forums section. More chance that forums people might look into it.

7

There have been problems over the past couple of years when a workstation
is using IPv6, the server side is using IPv6, but something in the middle
(usually the local router, whether at the airport, work, or home) does
not. The workstation asks for the AAAA record (via Ipv4) which dutifully
comes back with an IPv6 address. The workstation tries to access it, and
the local network doesn’t know what to do, so that is the end. Disabling
IPv6 on your workstation usually fixes it, though that’s just a
workaround. I guess another test would be to see if you can get anywhere
with IPv6 explicitly, using either netcat or openssl as you were doing.
If not, definitely a local network problem.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

8

You can of course use http://test-ipv6.com/ in different networks to see were it got stuck.

9

All tests are ok:

Test with IPv4 DNS record                       ok (0.202s) using ipv4
Test with IPv6 DNS record                       ok (0.202s) using ipv6
Test with Dual Stack DNS record                 ok (0.539s) using ipv6
Test for Dual Stack DNS and large packet        ok (0.223s) using ipv6
Test IPv4 without DNS                           ok (0.362s) using ipv4
Test IPv6 without DNS                           ok (0.369s) using ipv6
Test IPv6 large packet                          ok (0.707s) using ipv6
Test if your ISP's DNS server uses IPv6         ok (0.594s) using ipv6
Find IPv4 Service Provider                      ok (0.574s) using ipv4 ASN 9143
Find IPv6 Service Provider                      ok (0.553s) using ipv6 ASN 60781
10

Via another connection problem I came to a solution.

At some point, I was curious about the whois for a particular domain, but got “fgets: Connection reset by peer”. I googled for “behind router fgets: Connection reset by peer”, found a stackoverflow article (B. Kannel Bug) which lead to an ubuntu article with more info.

I suspected an MTU issue (more about that later). On my desktop PC, I set the MTU of the network interface to the same as that of the sixxs interface on my router (1280) and after that my problem had disappeared.

The Ubuntu article contained an iptables rule for IPv4:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Executed on my router (with iptables → ip6tables for IPv6), this was a more general solution.

Coincidentally, SuSEfirewall2 already contains such a rule, but only for IPv4 (around line 1491). I changed the script like this:

--- /usr/sbin/SuSEfirewall2.orig        2015-03-03 11:08:14.588108479 +0100
+++ /usr/sbin/SuSEfirewall2     2015-03-03 12:36:16.611408851 +0100
@@ -1491,2 +1491,3 @@
        $IPTABLES -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
+       $IP6TABLES -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
     fi

Apparently “-t mangle” is not required.

This is what I am going to use for now.

man iptables-extensions has more info (search for TCPMSS).

Kind regards,

Leen