http://test-ipv6.com/ works but httpS://test-ipv6.com/ doesn’t - TLS handshake stuck with IPv6

paulgreg

I’ve configured a pfSense router (2.4.3-RELEASE-p1) to use a /64 IPv6 subnet from my ISP on my LAN (free.fr in France like explained here).

The IPv6 configuration seems to work on a host on my LAN as I’ve got a 10/10 score on http://test-ipv6.com/ (with the message « Your IPv6 address on the public Internet appears to be 2a01:... »).

From LAN clients, I can ping IPv6 hosts.
I can also browse some websites using IPv6 from a browser (like https://www.google.com/ or https://www.qwant.fr/).

However, some websites can’t be loaded at all (like https://www.fast.com/ or https://www.free.fr/).
httpS://test-ipv6.com is one of them and it’s telling me « No IPv6 address detected » with a score of 0/10 (as I said before, I’ve got 10/10 on same site in plain http).

I’ve tried to use curl to inspect what is going on.
Here’s what I’ve got this on https://www.fast.com :

➜  ~ curl -XGET -I -vvvv https://www.fast.com
* Rebuilt URL to: https://www.fast.com/
*   Trying 2a02:26f0:135:28d::24fe...
* TCP_NODELAY set
* Connected to www.fast.com (2a02:26f0:135:28d::24fe) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection:
ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
# it is then stuck here... 
# After a long wait, I’ve got this :
* Unknown SSL protocol error in connection to www.fast.com:443
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to www.fast.com:443

When I’m doing the same on https://www.google.com :

➜  ~ curl -XGET -I -vvvv https://www.google.com
*   Trying 2a00:1450:400b:803::2004...
* TCP_NODELAY set
* Connected to www.google.com (2a00:1450:400b:803::2004) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* 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 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=Mountain View; O=Google LLC; CN=www.google.com
*  start date: Aug  7 18:34:32 2018 GMT
*  expire date: Oct 16 18:28:00 2018 GMT
*  subjectAltName: host "www.google.com" matched cert's "www.google.com"
*  issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3
*  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 0x55d17c77bdc0)
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.52.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
HTTP/2 200
< date: Tue, 28 Aug 2018 06:08:03 GMT
date: Tue, 28 Aug 2018 06:08:03 GMT
...

<
* Curl_http_done: called premature == 0
* Connection #0 to host www.google.com left intact

Does someone have any idea about what can cause a TLS handshake to be stuck on some website and not on others ?

May it be a bad IPv6 configuration ? Some firewall rules ?

NogBadTheBad

@paulgreg said in http://test-ipv6.com/ works but httpS://test-ipv6.com/ doesn’t - TLS handshake stuck with IPv6:

TLSv1.2 (OUT), TLS handshake, Client hello (1)

Works OK here, not that it's of any help to you :(

mac-pro:~ andy$ curl -XGET -I -vvvv https://www.fast.com
* Rebuilt URL to: https://www.fast.com/
*   Trying 2a02:26f0:4000:2b6::24fe...
* TCP_NODELAY set
* Connected to www.fast.com (2a02:26f0:4000:2b6::24fe) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* 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, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=CA; L=Los Gatos; O=Netflix, Inc.; OU=Operations; CN=fast.com
*  start date: Jan 16 00:00:00 2018 GMT
*  expire date: Jan 16 12:00:00 2020 GMT
*  subjectAltName: host "www.fast.com" matched cert's "www.fast.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure 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 0x7fe55a000000)
> GET / HTTP/2
> Host: www.fast.com
> User-Agent: curl/7.54.0
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 301 
HTTP/2 301 
< server: AkamaiGHost
server: AkamaiGHost
< content-length: 0
content-length: 0
< location: https://fast.com/
location: https://fast.com/
< cache-control: max-age=0
cache-control: max-age=0
< expires: Tue, 28 Aug 2018 13:37:21 GMT
expires: Tue, 28 Aug 2018 13:37:21 GMT
< date: Tue, 28 Aug 2018 13:37:21 GMT
date: Tue, 28 Aug 2018 13:37:21 GMT
< vary: Accept-Language
vary: Accept-Language
< strict-transport-security: max-age=31536000
strict-transport-security: max-age=31536000

< 
* Connection #0 to host www.fast.com left intact
mac-pro:~ andy$

Ah I'm resolving fast.com a differnet ipv6 address 2a02:26f0:4000:2b6::24fe

Gertjan

Same here.

But, I'm not using Free. Worse : Orange, so no IPv6 at all.
I'm using the next to perfect IPv6 setup : he.net

curl -XGET -I -vvvv https://www.fast.com
* Rebuilt URL to: https://www.fast.com/
*   Trying 2a02:26f0:7b:38e::24fe...
* TCP_NODELAY set
*   Trying 2.19.231.148...
* TCP_NODELAY set
* Connected to www.fast.com (2a02:26f0:7b:38e::24fe) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
 CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* 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, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=CA; L=Los Gatos; O=Netflix, Inc.; OU=Operations; CN=fast.com
*  start date: Jan 16 00:00:00 2018 GMT
*  expire date: Jan 16 12:00:00 2020 GMT
*  subjectAltName: host "www.fast.com" matched cert's "www.fast.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure 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 0x803a94580)
> GET / HTTP/2
> Host: www.fast.com
> User-Agent: curl/7.58.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 301
HTTP/2 301
< server: AkamaiGHost
server: AkamaiGHost
< content-length: 0
content-length: 0
< location: https://fast.com/
location: https://fast.com/
< cache-control: max-age=0
cache-control: max-age=0
< expires: Tue, 28 Aug 2018 13:58:10 GMT
expires: Tue, 28 Aug 2018 13:58:10 GMT
< date: Tue, 28 Aug 2018 13:58:10 GMT
date: Tue, 28 Aug 2018 13:58:10 GMT
< vary: Accept-Language
vary: Accept-Language
< strict-transport-security: max-age=31536000
strict-transport-security: max-age=31536000

<
* Connection #0 to host www.fast.com left intact

Now for the strange part :
You : CAfile: /etc/ssl/certs/ca-certificates.crt
@NogBadTheBad : CAfile : /etc/ssl/cert.pem
Me : CAfile: /usr/local/share/certs/ca-root-nss.crt

On my pfSense setup, the directory , /etc/ssl/certs/ doesn't even exist !
The file /etc/ssl/cert.pem exists. (and, oh, stupid me, it point to

lrwxr-xr-x  1 root  wheel  38 Mar 16 17:28 /etc/ssl/cert.pem -> /usr/local/share/certs/ca-root-nss.crt

)
I don't understand why 3 different certs files are used on 3 different pfSense setups.

You are running 2.4.3, right ??

edit : another difference :
I obtained an IPv4 and IPv6

*   Trying 2a02:26f0:7b:38e::24fe...
* TCP_NODELAY set
*   Trying 2.19.231.148...
* TCP_NODELAY set

My "curl" decided to use the IPv6 ....

paulgreg

Sorry, I forgot to tell that the curl command above has been launched on one of the LAN client (a linux machine).
But you’re right, I’ll try directly on the pfSense box.

Gertjan

@paulgreg said in http://test-ipv6.com/ works but httpS://test-ipv6.com/ doesn’t - TLS handshake stuck with IPv6:

Sorry, I forgot to tell that the curl command above has been launched on one of the LAN client (a linux machine).

Yes, lol, I just ran the same command on a Debian 9 server (very IPv6 compatible), and there the path was of course, "/etc/ssl/certs/" which is valid for that OS.

NogBadTheBad

@gertjan

Did my test from my Mac.

From pfSense:-

[2.4.3-RELEASE][admin@pfsense]/root: curl -XGET -I -vvvv https://www.fast.com
* Rebuilt URL to: https://www.fast.com/
*   Trying 2a02:26f0:4000:2b1::24fe...
* TCP_NODELAY set
* Connected to www.fast.com (2a02:26f0:4000:2b1::24fe) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* 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, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=CA; L=Los Gatos; O=Netflix, Inc.; OU=Operations; CN=fast.com
*  start date: Jan 16 00:00:00 2018 GMT
*  expire date: Jan 16 12:00:00 2020 GMT
*  subjectAltName: host "www.fast.com" matched cert's "www.fast.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure 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 0x803a94580)
> GET / HTTP/2
> Host: www.fast.com
> User-Agent: curl/7.58.0
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 301 
HTTP/2 301 
< server: AkamaiGHost
server: AkamaiGHost
< content-length: 0
content-length: 0
< location: https://fast.com/
location: https://fast.com/
< cache-control: max-age=0
cache-control: max-age=0
< expires: Tue, 28 Aug 2018 14:33:28 GMT
expires: Tue, 28 Aug 2018 14:33:28 GMT
< date: Tue, 28 Aug 2018 14:33:28 GMT
date: Tue, 28 Aug 2018 14:33:28 GMT
< vary: Accept-Language
vary: Accept-Language
< strict-transport-security: max-age=31536000
strict-transport-security: max-age=31536000

< 
* Connection #0 to host www.fast.com left intact
[2.4.3-RELEASE][admin@pfsense]/root:

paulgreg

I’ve tested from my pfSense box and it works there :

$ curl -XGET -I -vvvv https://www.fast.com/
Trying 2a02:26f0:e1:481::24fe...
* TCP_NODELAY set
* Connected to www.fast.com (2a02:26f0:e1:481::24fe) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [102 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2509 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=CA; L=Los Gatos; O=Netflix, Inc.; OU=Operations; CN=fast.com
*  start date: Jan 16 00:00:00 2018 GMT
*  expire date: Jan 16 12:00:00 2020 GMT
*  subjectAltName: host "www.fast.com" matched cert's "www.fast.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure 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
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x803a94580)
} [5 bytes data]
> GET / HTTP/2
> Host: www.fast.com
> User-Agent: curl/7.58.0
> Accept: */*
>
{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
} [5 bytes data]
< HTTP/2 301
...
< location: https://fast.com/
...

* Connection #0 to host www.fast.com left intact

paulgreg

I’ve found an other post explaining the same issue I had : https://forum.netgate.com/topic/73573/massive-http-ipv6-connectivity-issues/8
The solution explained there (setting a MSS to 1220 in my LAN interface) fixed the issue.
I’m not sure however that 1220 is the best value for my configuration.
Any idea how to define the best value ?

Grimson

@paulgreg said in http://test-ipv6.com/ works but httpS://test-ipv6.com/ doesn’t - TLS handshake stuck with IPv6:

I’m not sure however that 1220 is the best value for my configuration.
Any idea how to define the best value ?

Experiment with different values. Or ask your ISP what they use on their end and hope for a useful answer.

Gertjan

Not trying to be an expert here, but "1220" seems a low value.
It's like your IPv6 connection is being tunneled, and not really a native one.

johnpoz

Yeah 1220 seems a bit low.. 1280 is normally what is set when this is a problem

http://test-ipv6.com/faq_pmtud.html

Playing devils advocate here, to point out the simple solution.. What are you accessing that requires IPv6 may I ask? The simple solution is just turn off IPv6 ;) While we all agree it is the future - what resource are you needing to access that is only IPv6? I have yet to find one.. My current isp doesn't even have ipv6 yet, I just use a HE tunnel for playing with ipv6..

My previous isp - suppose to be one of the leaders in ipv6 deployment across the us still pretty borked if you asked me..So I still used a HE tunnel - because its rock solid, etc. Easier to deploy too - and always have the same /48 no matter what ISP I move too, etc.

But most of my vlans and devices do not get IPv6.. Since there isn't actually a NEED for it that I have found.. Once you need IPv6 to get to some common resource - then yeah its a requirement.. Until that time its "optional" if using the option causes you grief there is the "option" of disabling that option -- just saying ;)

Doing your test from one of my Ipv6 boxes (serves up ntp on ipv6 to ntp pool) has no issues accessing that fast site.. And its not using 1220.

pi@ntp:~ $ curl -XGET -I -vvvv https://www.fast.com
* Rebuilt URL to: https://www.fast.com/
*   Trying 2600:1407:10:3b5::24fe...
* TCP_NODELAY set
* Connected to www.fast.com (2600:1407:10:3b5::24fe) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* 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, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=CA; L=Los Gatos; O=Netflix, Inc.; OU=Operations; CN=fast.com
*  start date: Jan 16 00:00:00 2018 GMT
*  expire date: Jan 16 12:00:00 2020 GMT
*  subjectAltName: host "www.fast.com" matched cert's "www.fast.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure 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 0x1bc6e48)
> GET / HTTP/1.1
> Host: www.fast.com
> User-Agent: curl/7.52.1
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 301 
HTTP/2 301 
< server: AkamaiGHost
server: AkamaiGHost
< content-length: 0
content-length: 0
< location: https://fast.com/
location: https://fast.com/
< cache-control: max-age=0
cache-control: max-age=0
< expires: Thu, 30 Aug 2018 09:04:02 GMT
expires: Thu, 30 Aug 2018 09:04:02 GMT
< date: Thu, 30 Aug 2018 09:04:02 GMT
date: Thu, 30 Aug 2018 09:04:02 GMT
< vary: Accept-Language
vary: Accept-Language
< strict-transport-security: max-age=31536000
strict-transport-security: max-age=31536000

< 
* Curl_http_done: called premature == 0
* Connection #0 to host www.fast.com left intact
pi@ntp:~ $

Check out
http://www.letmecheck.it/mtu-test.php

That is test to my IPv6 ntp server - and its going through the he tunnel..

Or try simple tracepath command from linux, or windows believe you can use mturoute?

paulgreg

I’m trying to make IPv6 functional in my LAN for educational purpose but also because I think we (as the IT industry) should move to it.

Many thanks for the above resources and links. It will be very helpful to find the best MMS value for my setup !

johnpoz

While I agree with you on should move - the problem is to be honest is there are many many things that need to get ironed out before it becomes actually really world wide viable ;)

Part of the problem in my personal opinion is the horrible rollouts some ISP do - they clearly do not actually understand the tech or even the address space... I doubt many of them have even breezed over some of the rfc's to be honest.. And then software writers don't get it either, and are still thinking with ipv4 mindset and nat being the norm, etc.. Shoot many of the software writers can not even do ipv4 nat correctly.. I mean how hard is it to state what EXACT ports need to be open inbound for their software to function inbound unsolicited.. But when you look at their docs they list ports like 80 and 53 as needing to be "opened" so users think they need to port forward those to the device behind a nat, etc. When those are only needed outbound, etc..

I hear ya it can be frustrating! 1280 is the MIN for ipv6 needs to support.. But seems you can only do 1220?? Something wrong there.. Where are you hitting that 1220 limit.. At your ISP? Are you not getting Packet Too Big Messages? Per RFCs these need to be sent and firewalls need to allow them.. Or yeah your going to run into problems with pmtud...

Can we see that tracepath test from your box?

So your just playing with this on your test network, your not trying to use this in any sort of production? Be it work/home? Like I said I have a few segments that have ipv6, and a few hosts that use it.. I can toggle it on or off on my PC for example.. Normally its toggled off ;) Since I think it really causes more grief than any sort of benefit.. I am quite sure I will be retired before it becomes mainstream in the enterprise anyway.. Try as I might I have not gotten any traction for ipv6, and have had zero customers come forth and say hey we need it.. Have seen it on a few RFPs that say it needs to be supported.. But those come down to their IT guy copy paste info they "need".

JKnott

@johnpoz said in http://test-ipv6.com/ works but httpS://test-ipv6.com/ doesn’t - TLS handshake stuck with IPv6:

Yeah 1220 seems a bit low.. 1280 is normally what is set when this is a problem

The minimum IPv6 is 1280, which results in a MSS of 1240 after deducting 40 bytes for the header.

paulgreg

@johnpoz
The maximum working MSS is 1440 in my LAN interface setup in pfSense.
1280 also works.
(the tracepath result gave me the same result as for you)
As I said, I used 1220 because I found that post https://forum.netgate.com/topic/73573/massive-http-ipv6-connectivity-issues/8 where the solution was to set the MSS to 1220.

I’m setting IPv6 in my « home » LAN, to learn more about IPv6 but also to have a fully functional IPv6 connection. I hope that’s the only problem I’ll find about my IPv6 setup.

Again, thanks for all the resource you shared.