Messages

I don't know. I've experienced this with chromium (IPv6) only but not with Firefox (IPv4). But Hybridized Kyber Support was not enabled in Firefox.

Sorry seems not to be NPTv6 alone. This suggest the WAN MTU (PPPoE) the cause:

https://issues.chromium.org/issues/336007383

In the NPTv6 setup without PPPoE it works. In case of other questions I will open an other thread.

EDIT: I confirm that setting MSS on LAN to 1452 fixes the issue.

EDIT2: NPTv6 probably has nothing to do with it. I had tested it in the guest WiFi with public IPv6. But I just guess that the WiFi has an effect on the MTU problem.

NPTv6 seems to break TLS 1.3 Hybridized Kyber Support in Chromium. Any idea why?

I also don't have any issues on 24.7.5 with with PPPoE, Wireguard and IPv4/6.

@RamSense Have you tried your trick also on 24.7.5?

Using 64:ff9b::/96 could have similar problematic side effects like when using .local as internal DNS TLD. I will stick to ULAs.

https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-update-06.html

Thanks for the info. The RFC demands that the preferences must be changeable, but unfortunately the local ULA prefix is not automatically preferred. Windows, Linux and Freebsd already behave differently by default: Linux prefers ULAs over IPv4, Windows and Freebsd do not. With additional GUAs in the DNS, the chaos would unfortunately be complete.

So unfortunately I only see two possibilities:
1) I get my own GUA prefix and use it with NPTv6 if necessary. The advantage would be that more runs via IPv6. However, apart from a good feeling, I haven't gained much from this either.
2) Continue to use ULAs and wait and see. This leaves a lot of traffic on IPv4 for the time being, but IPv6-only destinations can still be reached.

I will stick with the second option for the time being and wait and see. Normally I'm not a fan of this, but in this case I'm really not surprised that after 25 years of IPv6 many sites are still IPv4-only. Many things are still not thought through.

That's not what I meant. The question is, if I have GUA and ULA in the DNS of my network (which is unavoidable due to dynamic DNS updates), is ULA preferred over GUA?

This would indeed be a possibility. The disadvantage would be that there would again be a dependency on a service provider. I don't think anyone can guarantee that the service will last forever.

In this respect, I would prefer to stay with the ULAs. The only question is whether ULA to ULA is always preferred over GUA to GUA. I hope so, because otherwise ULAs would be really broken and I would get the problems again that I originally wanted to avoid with ULAs.

I don't really have any major problems with the ULAs. Internally, many things now run via IPv6 instead of IPv4. If IPv4 were to be switched off on the Internet tomorrow, I would still have Internet access. In this respect, I have gained a lot and still have an independent local network.


I therefore see it as a good decision to introduce IPv6 on the basis of ULAs and NPTv6. As a private user, it is difficult to get a fixed GUA prefix, which incidentally also has disadvantages for privacy (I know that there are also other tracking options). In this respect, you actually want to have two prefixes: A fixed one for internal use and a dynamic one for internet traffic. The former is the intended use case of the ULAs and the standard allows for ULAs and GUAs to be used in parallel.

NPTv6 has its limitations when using ULAs, which is why it may make sense to roll out both prefixes directly to the internal networks. Does anyone know whether this can already be implemented in a stable manner? Or do the problems sketched in this thread still apply?

Unfortunately, the same problem seems to exist with Wireguard.

Otherwise, NTPv6 is working for now and I finally have IPv6. Unfortunately, IPv4 is preferred over ULA to GUA, which is why I will probably roll out dynamic GUAs in addition to the ULAs sooner or later. Unless there is a way to change this preference centrally via OPNsense.

Has anyone tested NPTv6 with OpenVPN? It is currently not working for me, although the OpenVPN network has the same /57 prefix as the other /64 subnets. The rule should work accordingly, but I also created an explicit rule as a test.

As a workaround, I am tracking the guest WiFi interface in the NTPv6 rule as it has a global IPv6 address. This seems to work so far.

I have two sites, each with their own VLANs, which are connected via Wireguard. Both are only assigned a dynamic /56 IPv6 prefix by the Internet service provider. This is known to cause some complications in the area of DNS and VPN firewall: e.g. devices could enter the changing IPs in the internal DNS, but these would not be routed via the VPN.

I think the easiest way would be to use a private IPv6 prefix and make it accessible to the outside world via NPTv6. As of OPNsense 24.1.x there is the new option "Track interface". However, you can only create a rule with this if the IPv6 interface is not configured statically but via track interface. Unfortunately, this is unsuitable for this use case, as I then have all kinds of problems with the dynamic IPs in the network.

How should I deal with this problem? I would like to be able to safely activate IPv6 in the internal network at some point.

The PPPoE performance on 24.1 (APU2) seems to be quite better (between 350 and 400 instead of between 170 and 320  MBit/s)  so fare :)