Messages

@franco Nice! That's just the foundation though, correct? The dhcp6c_script doesn't do anything with this information yet, or does it?

Option 64 is the AFTR FQDN for DS-Lite. OPNsense doesn't support configuring DS-Lite automatically using this option, but dhcp6c should just ignore it - unless it's indeed malformed. I'd perform a packet capture to confirm.

Cheers
Maurice

Since it seems you're not using OPNsense for DNS at all, this is more likely an issue with your DNS servers. While OPNsense advertises the DNS server addresses (using DHCP / RAs), DNS requests are sent from the clients to the DNS servers, not to OPNsense.

Cheers
Maurice

@xpendable

https://github.com/opnsense/hostwatch/issues/13

Then the code in dhcp6c repo wasn't pulled correctly?

Pulled, compiled and installed correctly.

Or are you using the "no release" option, too?

Nope.

But I now made the next step and switched to opnsense-devel (26.1.b_143). ifconfig now shows pltime and vltime for the GUA on the tracking LAN interface. So it seems devel is indeed required for this to work.

Did not apply the multi-dhcp6c patch yet, maybe tomorrow.

Great new radvd features by the way, like PREF64! 👍

Cheers
Maurice

Hey everyone,

Inspired by the recent hostwatch experience, I wanted to start a bit of a meta discussion about the Development / Community / Business versions of OPNsense and when to use which. It was my understanding that Development is for public testing, Community is ready for production (although a bit bleeding edge) and Business is extra stable for critical use cases.

From what I see on GitHub and the forum and from my own experience, hostwatch is still in the development phase. For example, a serious issue was reported a month ago and is still open. Nonetheless, it was now moved to the Community version and enabled by default. This feels like a beta test, which I was under the impression you needed to opt-in for by switching to the Development version.

Not blaming anyone, just interested in your opinions about what level of maturity you (can) expect in which version.

Development = beta, Community = stable, Business = extra stable?
Or Development = alpha, Community = beta, Business = stable?

Personally, I mostly use the Community version and occasionally switch to Development when I really need a feature which has not yet been released.

Cheers
Maurice

No it sounds to me that the dhcp6c service wasn't restarted.

I did reboot.

For the WAN interface, ifconfig only shows the addresses configured on the interface itself (obviously), not the delegated prefix. So no lifetime information for IA_PD there:

Code Select Expand

~ # ifconfig -L vtnet0
vtnet0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
        description: WAN_GPON (wan)
        options=ec07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS>
        ether 00:15:5d:2a:fe:16
        inet6 fe80::215:5dff:fe2a:fe16%vtnet0 prefixlen 64 scopeid 0x1
        inet6 2001:db8:5812:800::2 prefixlen 128 pltime 209 vltime 239
        media: Ethernet autoselect (10Gbase-T <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
For the tracking LAN interface, ifconfig doesn't show lifetimes:

Code Select Expand

~ # ifconfig -L vtnet2
vtnet2: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        description: LAN_IPv6 (lan)
        options=ec07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS>
        ether 00:15:5d:2a:fe:02
        inet6 fe80::215:5dff:fe2a:fe02%vtnet2 prefixlen 64 scopeid 0x3
        inet6 fd03:2148:cea2:1::1 prefixlen 64
        inet6 2001:db8:5812:801::1 prefixlen 64
        media: Ethernet autoselect (10Gbase-T <full-duplex>)
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
What does work is that the GUA gets removed from the tracking LAN interface when the valid lifetime of the prefix delegation expires. It just seems you can't see that lifetime anywhere.

Cheers
Maurice

You can do that, absolutely. I've been using the "tracking loopback interface" workaround for getting dynamic subnets into NPT for quite a while now and it works fine.

Be aware though that for your use case, NPT has limited use. As long as the WireGuard clients also have an IPv4 address, NPT will only be used when they need to access hosts which only have a GUA (no ULA, no IPv4).

Cheers
Maurice

Oh, I probably have to perform 2. (switch to development branch and apply patch) to see the IA_PD lifetime?

you can see configured lifetimes in ifconfig and with -L switch you can see how much is left

On the WAN interface, ifconfig shows the lifetime of the interface address (IA_NA). But where do I see the lifetime of the prefix (IA_PD)? On the tracking LAN interface, ifconfig does not show a lifetime.

NA was setting vltime and pltime correctly

I can confirm this. IA_NA pltime is lower than vltime: inet6 2001:db8:6490:5d00::2 prefixlen 128 pltime 270 vltime 300

from my testing so far dhcp6c renews far more frequently than pltime

From my testing, dhcp6c renews after half of vltime. So as long as pltime > vltime/2, no problem.

The key thing here is that we want to see the ifconfig -L times so we can actually distinguish which prefix was the last one assigned and use that as the primary one for e.g. radvd. Some ISPs renew with a new prefix but having the first one stick around and no way to distinguish because they both do not expire was suboptimal and at some point the old one disappears but there is no renew triggering a radvd reload so then the prefix stops working for clients.

Excellent! This has plagued me a lot and the workarounds I had to implement are nightmare fuel.

I was a bit surprised to find all these related bugs for just trying to do what the standard intended.

Unfortunately, I'm not surprised at all.

Cheers
Maurice

Hey Franco,

Multi-WAN IPv6 user here. :) WAN1 requests address + prefix, WAN2 only requests an address.

I performed 1. and don't see any immediate issues after the reboot.
Can we see the (remaining) lifetime somewhere? It doesn't seem to be reflected in the prefix lifetime advertised by radvd on tracking LAN interfaces.

If there aren't any issues in the next two days or so, I'll go ahead and test 2., too.

Cheers
Maurice

OPNsense 25.7.11 aarch64 packages and sets released. Includes hotfix 25.7.11_1.

Das hast Du aber einen ganz hübschen Stapel von Mechanismen beisammen, um "modern" zu sein.

"Modern zu sein" ist nicht die Motivation. Es geht darum, frühzeitig Erfahrungen mit Technologien zu sammeln, die mittelfristig unser aller Alltag sein werden. Und es hilft dabei, ein kleiner Teil der Lösung zu sein und nicht des Problems. Das Problem ist, dass zu viele warten, bis andere vorangehen und die Steine aus dem Weg räumen. So kommen wir aber nicht voran. Und gerade das Heimnetz / Home Lab ist prädestiniert für Bleeding Edge, denn kritische Infrastruktur ist das eher selten.

Bin gespannt auf das HOWTO dazu.

Das How-to zu DNS64 / NAT64 mit Tayga und Unbound habe ich vor Jahren geschrieben, das ist Teil der OPNsense-Doku.
Die Geschichte mit BIND als authoritativem DNS-Server für die internen Zonen und Unbound als rekursivem Resolver mit DNS64 und Forwarding zu BIND ist fast trivial, aber vielleicht ist das nur die Innenperspektive. ;)
Der Weg war tatsächlich steinig, so manches OPNsense-Feature musste erst implementiert und der eine oder andere Bug gefixt werden. Im jetzigen Zustand ist es aber relativ einfach zu konfigurieren. Vielleicht schreibe ich mal ein How-to für das Gesamtpaket.

Schlimm wenn es nicht die eine Lösung gibt

Die Qual der Wahl. Es gibt mehrere passable Lösungen und viele schlechte. ;)

Verstehe ich es grob richtig, dass aktuelle zwei Ansätze diskutiert werden. Der eine zielt möglichst auf IPv6 only ab und bindet IPv4 dort ein, wo nötig.

Richtig.

Führt aber zu einer komplexeren Konfiguration.

Einerseits komplexer durch DNS64 / NAT64 und ggfs. etwas mehr DNS-Konfiguration, andererseits einfacher dadurch, dass es in jedem Netz nur einen Stack gibt - entweder IPv6 oder IPv4. D. h. jeweils nur ein Satz Firewall-Regeln, entweder RAs + ggfs. DHCPv6 oder DHCPv4 etc. Was man unterm Strich präferiert ist eine individuelle Entscheidung.

Der andere Ansatz ist Dual-Stack, was vielleicht nicht optimal ist, jedoch einfacher zu konfigurieren/betreiben.

Es ist die konservativere, etablierte Lösung.

Welche Vorteile hat Ansatz 1 und welche Nachteile Ansatz 2?

Möchtest Du zwei Schritte vorausgehen und nimmst dafür den etwas holprigeren Weg auf dich? Dann Ansatz 1.
Gehst Du lieber zwei Schritte hinterher und hast dafür eine gut dokumentierte, ausgereifte Konfiguration? Dann Ansatz 2.
Beide Wege sind legitim.

Die feste IP kostet 10€  und ab dem 7. Monat dann 23€/mtl.

Wäre mir persönlich auch zu teuer, ist aber wieder eine individuelle Entscheidung. Privat habe ich momentan auch nur ein dynamisches Präfix, einzig aus Kostengründen. Das erfordert schon einige Klimmzüge mit ULAs, DynDNS etc. Bei meinem vorherigen ISP hatte ich ein quasi statisches Präfix und das war wirklich wesentlich einfacher zu handhaben.

nutze nur DynDNS für IPv4 und IPv6

Von außen ist mein Heimnetz ausschließlich über IPv6 erreichbar (zur Zeit ebenfalls per DynDNS). Macht es auch wieder einfacher und reicht für meine Anforderungen völlig, spätestens seit es IPv6 hierzulande in allen Mobilfunknetzen gibt. Und falls mein ISP morgen auf DS-Lite umstellt bzw. €€€ für "Premium Dual Stack" möchte, dann bin ich tiefenentspannt und sage: Mach doch, kannst IPv4 gerne abschalten.

@n3 Kannst Du so machen, wobei Du dann auch im Client-Netz GUA + ULA verwenden solltest.
IPv4-only-Clients am besten in ein eigenes IPv4-only-LAN packen. Über Tayga kannst Du dann die Brücke zu den IPv6-LANs herstellen.

Für einen Fünfer mehr würde ich definitiv das statische GUA-Präfix nehmen. Das hast Du zwar auch nicht bis in alle Ewigkeit, anders als z. B. eine Telefonnummer kann es nicht "portiert" werden und ist spätestens beim Provider-Wechsel weg. Aber ein manuelles Renumbering alle paar Jahre ist etwas völlig anderes als ein sich ständig änderndes dynamisches Präfix.

@meyergru

Den Trick, den Maurice nennt, mal außen vorgelassen - dabei würdest Du den ULA-Clients die IPv4 niemals zeigen. Das bedeutet natürlich auch, dass diese Clients niemals irgendwelche IPv4 gezeigt bekommen - Zugriff auf IPv4-only Geräte im IoT Netz (z.B. schaltbare Steckdosen) ist damit dann per DNS-Name nicht mehr drin.

Doch, natürlich. DNS64 (Unbound-Feature) synthetisiert AAAA-Records, falls es nur A-Records gibt. Und NAT64 (Tayga-Plugin) übersetzt zwischen IPv6 und IPv4. Mein Smartphone im IPv6-only-Netz greift so z. B. problemlos auf Smart Home-Kram im IPv4-only-Netz zu.

@bimbar Ein Reverse Proxy mag für manche interne Dienste eine Alternative zu NAT64 sein, löst aber nicht das Problem, dass es noch ein klein wenig dauern wird, bis sämtliche Services im Internet über IPv6 erreichbar sein werden. Ohne NAT64 wirst Du daher noch bis zum Sankt-Nimmerleins-Tag Dual Stack im LAN fahren müssen.