IPv6 connection problems.

-flo- 0 · Oct 13, 2024, 6:30 PM

I may have an issue with an IPv6 connection.

If I try curl -v -4 <server1> and curl -v -6 <server1> the first command works, the second does not. There simply is no answer from the server. When using IPv6 I can trace the outgoing connection in the firewall and I can see states created as expected, however the server never answers.

Shouldn't the states make sure that any packets received from the server for this connection are accepted and pfSense should route these to my machine?

How would I investigate whether my own network is the reason?

P.S. IPv6 test pages tell me I'm fine.

Gertjan · Oct 15, 2024, 6:16 AM

@flo-0

What you can do :
Make sure IPv6 is set up correctly on your side = pfSense.
Make sure ..... that your ISP didn't lie to you, and that hey actually offer broken IPv6.
And then there is the question : is the interconnection between your ISP and the rest of the work 'ok' ?
Make sure that your 'server' supports IPv6.

The two tests on my side :

[24.03-RELEASE][root@pfSense.bhf.tld]/root: curl -v -4 www.google.fr
* Host www.google.fr:80 was resolved.
* IPv6: (none)
* IPv4: 142.250.201.3
*   Trying 142.250.201.3:80...
* Connected to www.google.fr (142.250.201.3) port 80
> GET / HTTP/1.1
> Host: www.google.fr
> User-Agent: curl/8.6.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 14 Oct 2024 12:33:56 GMT
< Expires: -1
< Cache-Control: private, max-age=0
< Content-Type: text/html; charset=ISO-8859-1
< Content-Security-Policy-Report-Only: object-src 'none';base-uri 'self';script-src 'nonce-2_vkQTU-mpFzLzTGEP2pOQ' 'strict-dynamic' 'report-sample' 'unsafe-eval' 'unsafe-          inline' https: http:;report-uri https://csp.withgoogle.com/csp/gws/other-hp
< Server: gws
< X-XSS-Protection: 0
< X-Frame-Options: SAMEORIGIN
< Set-Cookie: AEC=AVYB7cpBHIBmaIOfOGXuB1b7cRhoz8o_Wbp5CdIMjq9mQn-K4OlVhv_jHV8; expires=Sat, 12-Apr-2025 12:33:56 GMT; path=/; domain=.google.fr; Secure; HttpOnly; SameSit          e=lax
< Accept-Ranges: none
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
<

-------> the htmpl page here


[24.03-RELEASE][root@pfSense.bhf.tld]/root: curl -v -6 www.google.fr
* Host www.google.fr:80 was resolved.
* IPv6: 2a00:1450:4007:80e::2003
* IPv4: (none)
*   Trying [2a00:1450:4007:80e::2003]:80...
* Connected to www.google.fr (2a00:1450:4007:80e::2003) port 80
> GET / HTTP/1.1
> Host: www.google.fr
> User-Agent: curl/8.6.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 14 Oct 2024 12:34:05 GMT
< Expires: -1
< Cache-Control: private, max-age=0
< Content-Type: text/html; charset=ISO-8859-1
< Content-Security-Policy-Report-Only: object-src 'none';base-uri 'self';script-src 'nonce-Y7O21pAWGeCOtSDEzAGzgw' 'strict-dynamic' 'report-sample' 'unsafe-eval' 'unsafe-          inline' https: http:;report-uri https://csp.withgoogle.com/csp/gws/other-hp
< Server: gws
< X-XSS-Protection: 0
< X-Frame-Options: SAMEORIGIN
< Set-Cookie: AEC=AVYB7cpbVFwVUkTHDhGHv1JC_UY0hRyjw1pIx5RTGk30yfdE59lxRuo6YA; expires=Sat, 12-Apr-2025 12:34:05 GMT; path=/; domain=.google.fr; Secure; HttpOnly; SameSite          =lax
< Accept-Ranges: none
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
<
 
-------> the htmpl page here

So I tend to say : looks fine.

-flo- 0 · Oct 15, 2024, 6:16 AM

@Gertjan

It's not that I didn't already check with different servers. IPv6 seems to work with another server, see below. That means IPv6 should be ok in my network. One specific server however shows the problem. I would conclude that this indicates a problem with the server.

However when I check the server which has the problem from another network with IPv6 it seems to work.

May I humbly ask you to repeat your test with https://mirrors.kodi.tv. and show the results here? (You probably know KODI but just in case you don't: KODI is an open source media center available on different platforms. After installation it connects to this server to pull updates.)

I'm at a total loss at the moment. If this is something else (not an IPv6 problem), then why does it only appear when using IPv6? If IPv6 works on my network, why the problem with a specific server?

(Btw. my other question about the AAAA records was related to this problem: I worked around the problem by forcing KODI to use IPv4.)

Using -6 with spiegel.de:

fu@FlosPro ~ % curl -v -6 https://spiegel.de
* Host spiegel.de:443 was resolved.
* IPv6: ::ffff:128.65.210.8
* IPv4: (none)
*   Trying [::ffff:128.65.210.8]:443...
* Connected to spiegel.de (::ffff:128.65.210.8) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=www.spiegel.de
*  start date: Nov  1 00:00:00 2023 GMT
*  expire date: Dec  1 23:59:59 2024 GMT
*  subjectAltName: host "spiegel.de" matched cert's "spiegel.de"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://spiegel.de/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: spiegel.de]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: spiegel.de
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/2 301 
< location: https://www.spiegel.de/
< date: Tue, 15 Oct 2024 06:02:38 GMT
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
< via: 1.1 google
< 
* Connection #0 to host spiegel.de left intact

Using -6 with mirrors.kodi.tv it:

fu@FlosPro ~ % curl -v -6 https://mirrors.kodi.tv
* Host mirrors.kodi.tv:443 was resolved.
* IPv6: 2607:f5b2:1:a002:10::248
* IPv4: (none)
*   Trying [2607:f5b2:1:a002:10::248]:443...
* Connected to mirrors.kodi.tv (2607:f5b2:1:a002:10::248) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* Recv failure: Connection reset by peer
* LibreSSL/3.3.6: error:02FFF036:system library:func(4095):Connection reset by peer
* Closing connection
curl: (35) Recv failure: Connection reset by peer

Using -4 with this same server:

fu@FlosPro ~ % curl -v -4 https://mirrors.kodi.tv
* Host mirrors.kodi.tv:443 was resolved.
* IPv6: (none)
* IPv4: 23.19.87.248
*   Trying 23.19.87.248:443...
* Connected to mirrors.kodi.tv (23.19.87.248) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.kodi.tv
*  start date: Oct  2 19:08:41 2024 GMT
*  expire date: Dec 31 19:08:40 2024 GMT
*  subjectAltName: host "mirrors.kodi.tv" matched cert's "*.kodi.tv"
*  issuer: C=US; O=Let's Encrypt; CN=R10
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://mirrors.kodi.tv/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: mirrors.kodi.tv]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: mirrors.kodi.tv
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/2 200 
[...]

-flo- 0 · Oct 15, 2024, 6:20 AM

I forgot to mention: For the tests in the previous post I removed my workaround mentioned in the post.

Gertjan · Oct 15, 2024, 6:52 AM

@flo-0 said in IPv6 connection problems.:

https://mirrors.kodi.tv

Works fine with IPv6 :

What is this :

@flo-0 said in IPv6 connection problems.:

LibreSSL/3.3.6:

?

When I 'curl' from pfSense :

[24.03-RELEASE][root@pfSense.bhf.tld]/root: curl -v -6 https://mirrors.kodi.tv
* Host mirrors.kodi.tv:443 was resolved.
* IPv6: 2607:f5b2:1:a002:10::248
* IPv4: (none)
*   Trying [2607:f5b2:1:a002:10::248]:443...
* Connected to mirrors.kodi.tv (2607:f5b2:1:a002:10::248) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: none
*  CApath: /etc/ssl/certs/
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.kodi.tv
*  start date: Oct  2 19:08:41 2024 GMT
*  expire date: Dec 31 19:08:40 2024 GMT
*  subjectAltName: host "mirrors.kodi.tv" matched cert's "*.kodi.tv"
*  issuer: C=US; O=Let's Encrypt; CN=R10
*  SSL certificate verify ok.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
....

So : TLS 1.3 - not the way older 1.2
No have no TLS errors.

Your connection :

@flo-0 said in IPv6 connection problems.:

Recv failure: Connection reset by peer

LibreSSL/3.3.6: error:02FFF036:system library:func(4095):Connection reset by peer

Closing connection
curl: (35) Recv failure: Connection reset by peer

again : what is LibreSSL ?

-flo- 0 · Oct 15, 2024, 7:17 AM

@Gertjan

I can open the mirrors.kodi.tv with Chrome on my machine just fine. According to the browser console Chrome apparently uses IPv6 from within my network.

LibreSSL is an OpenSSL fork used by Mac OS (and AFAIK other BSDs). The output is somewhat different from OpenSSL but when the connection with kodi.tv works it is TLS1.3 as well (see above). So the TLS version is probably not the cause. Anyway LibreSSL is used in the IPv4 connection as well.

When I connect from my pfSense console it works.

Maybe LibreSSL is the culprit?

But: KODI uses OpenSSL. I run KODI on a Fire TV Stick (different machine, different SSL stack, same error).

Gertjan · Oct 15, 2024, 8:09 AM

@flo-0 said in IPv6 connection problems.:

LibreSSL is an OpenSSL fork used by Mac OS (and AFAIK other BSDs). The output is somewhat different from OpenSSL but when the connection with kodi.tv works it is TLS1.3 as well (see above). So the TLS version is probably not the cause. Anyway LibreSSL is used in the IPv4 connection as well.

Your post :

Using -6 with mirrors.kodi.tv it:

fu@FlosPro ~ % curl -v -6 https://mirrors.kodi.tv
* Host mirrors.kodi.tv:443 was resolved.
* IPv6: 2607:f5b2:1:a002:10::248
* IPv4: (none)
*   Trying [2607:f5b2:1:a002:10::248]:443...
* Connected to mirrors.kodi.tv (2607:f5b2:1:a002:10::248) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* Recv failure: Connection reset by peer
* LibreSSL/3.3.6: error:02FFF036:system library:func(4095):Connection reset by peer
* Closing connection
....

On the fu@FlosPro device, LibreSSL errors out.

For me, IPv6 is just fine. It's an TLS error.

spiegel.de = not IPv6 ready, only IPv4.

-flo- 0 · Oct 15, 2024, 8:51 AM

@Gertjan Okay thank you.

That means by incident I have the same TLS error in LibreSSL on Mac OS and in OpenSSL on the Fire TV Stick (Android) which only affects IPv6 connections.

Seems to be the only explanation.