Use IPv6 DHCPv6, Prefix Delegation without Link-Local (SLAAC)
-
@JKnott I've added an any/any rule on both WAN & LAN interface, and it still fails. It also fails consistently on all clients (Both Windows & Linux), which makes me believe it's a pfSense config issue.
I'm running 2.6.0.
-
Where are the hosts? Local? And the clients? If both on the LAN, then pfSense has nothing to do with it. However, as I said, it's not an IPv6 or address issue, if HTTP works and HTTPS doesn't.
-
@JKnott The host is on the regular interwebs, clients are on the LAN interface.
I've just tested it from the CLI of the pfSense machine and it works fine on the machine itself:
* Trying 2a01:4f8:c010:a08c::1:443... * Connected to ip6.nl (2a01:4f8:c010:a08c::1) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * CAfile: /usr/local/share/certs/ca-root-nss.crt * CApath: none * TLSv1.3 (OUT), TLS handshake, Client hello (1): * 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 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=ip6.nl * start date: May 10 13:11:37 2023 GMT * expire date: Aug 8 13:11:36 2023 GMT * subjectAltName: host "ip6.nl" matched cert's "ip6.nl" * issuer: C=US; O=Let's Encrypt; CN=R3 * SSL certificate verify ok. * Using HTTP2, server supports multiplexing * 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 0x801497800) > GET / HTTP/2 > Host: ip6.nl > user-agent: curl/7.80.0 > accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing * Connection state changed (MAX_CONCURRENT_STREAMS == 128)! < HTTP/2 200 < server: nginx < date: Thu, 01 Jun 2023 18:37:20 GMT < content-type: text/html < content-length: 10713 < last-modified: Wed, 01 Mar 2023 05:02:43 GMT < etag: "63fedc73-29d9" < accept-ranges: bytes < <!DOCTYPE html> *snip*I've tried disabling extra services that might interfere (don't know why, but testing couldn't hurt) like OpenVPN & HAProxy.
-
This post is deleted! -
@FireDrunk Even though this is not what you want to hear, you need to get to terms with your OCD because IPv6 is just not as tidy as IPv4.
Link Local is essential and needed for IPv6 to work, and the link local address on a host is the same on all interfaces (with the added %interfaceidentifier). It takes a while to get used to, but the real “OCD Killer” is the privacy features of IPv6 where hosts takes on dusins of IP addresses in the same /64 for different sessions over time (to not originate from one known IP). Firewall rules is EXTREMELY difficult compared to IPv4 if tight control is needed.
The whole original idea behind IPv6 is that we should no longer care about the client devices addresses - they should be very dynamic and resolvable by name only. But the needed DNS delivery and update features never really matured to that level (especially not in pfsense).
So we are back to trying to manage something that humans are not designed to cope with in terms of dynamics….I am a huge fan of IPv6, but honestly I think they botched it so badly with first insisting on slaac (that was not DNS feature complete), and now turning so heavily to DHCPv6 that Slaac is not really a good solution any more. This might see IPv6 take another 20 years to finally become the prevalent protocol.
Love the no fuss of using the official appliances :-)
-
@keyser said in Use IPv6 DHCPv6, Prefix Delegation without Link-Local (SLAAC):
and now turning so heavily to DHCPv6 that Slaac is not really a good solution any more
SLAAC now included RDNSS, which provides the DNS server. Just use the consistent address for DNS.
-
@JKnott said in Use IPv6 DHCPv6, Prefix Delegation without Link-Local (SLAAC):
SLAAC now included RDNSS, which provides the DNS server. Just use the consistent address for DNS.
Yes I know it was just pretty late to the party, and there is still no completely standardized way of asking - or if desired - requiring clients to automatically register their address in DNS when an address is aqquired. So we are still left with having to use a DHCP server, and have that register leases in DNS (Which incidentally never worked properly in pfSense).
So nameresolution is still crap, and with mac addresses going random combined with privacy session IPv6 adresses, we are on the path of complete lack of transparancy. -
@keyser said in Use IPv6 DHCPv6, Prefix Delegation without Link-Local (SLAAC):
This might see IPv6 take another 20 years to finally become the prevalent protocol.
There are probably experiences on this forum that differ by country or continent, when it comes to how networking, the internet, and ISP access works for them.
I've lived in the States, so I have a reasonable understanding of how disjointed things can be with internet access, the lack of common standards between ISPs and no common or national backhaul. But it is also the county that pushed the internet so hard with early adoption and product design, albeit slightly blinkered when it comes to what other continents do.
I now live in the UK; here the IPv6 adoption was rapid, supported at a national level, interfacing with the wider Europe and hosting all the early links across the Atlantic. IPv6 adoption by ISPs at core level was decades ago and IPv6 support by ISPs is universal. As such, most of the UK population has little appreciation of what protocols are in use or that most of their traffic is handled via IPv6.
Those of us who have more advanced networking needs clearly need to know more but even here I just note that over 65% of my household web-browsing is via IPv6 and most external DNS resolution happens via IPv6. In all respects IPv6 is the prevalent protocol, at least here.
Looking at the remaining IPv4 traffic a great deal of it comes from the US and, as a predominantly English-speeking nation, a great deal of our internet traffic comes from the States. The US has become an outlier with IPv6 adoption, for many reasons. Regrettably there are many network products designed in the 'Silicon Valley Experience' that have significant deficiencies in IPv6 support that then cascade to the bigger, global market - effectively spreading poor IPv6 experience to other countries (Ubiquity springs to mind, amongst many others).
I look at IPv4 as the poor relation to IPv6 - it is in a different league. I have more control with IPv6, more options and a massive 'free' address space. It is more prevalent, tends to be faster and offers a better experience. If we could just get the US to embrace it and fully support it in all their designs, the world would run just a little bit smoother!
️ -
@RobbieTT Yes, and I agree with that idea - even coming from denmark where IPv6 is nonexistant outside of a few small ISPs.
IPv6 is just not present in denmark - i think it has an adoptionrate of less than 5% if we discount 4/5G Mobile connections.If just Google, Facebook, youtube, Tiktok and Twitter would gang up and say: Hey: on january 1. 2025 non of social media platforms are available on IPv4, we could end this 20 year debacle. That would cause ALL ISP's that wish to survive past 2025 to adopt IPv6 NOW, and then there is really no need to support IPv4 for more than a few additional years because only slow enterprises would not have gone IPv6 at that time.
-
-
Part of the reason for the U.S. being so slow with IPv6 goes back to when IPv4 was created and most of the addresses went to the U.S.. As a result it didn't have the pressure of the IPv4 address shortage as the rest of the world did. Of course, when it was originally set up, it wasn't intended to be world wide. It was just to support defense researchers and grew from there. Also, back then, there wasn't a lot of data crossing the pond, as there wasn't much capacity until fibre came along.
