Messages

@Patrick Habe den PPPoE-Offloader mal hier dokumentiert:
https://gist.github.com/maurice-w/402eea6750738c7a6765219c34260283

Externe ONTs mit SFP-Uplink zum Router scheint es ja nicht zu geben?

Der OPNsense-Router wird doch ohnehin an einem Switch hängen? Und dieser Switch wird entweder einen freien SFP-Port haben (für das Zyxel) oder einen freien RJ45-Port (für ein Glasfasermodem 2)?

Der OPNsense-Router brauch keinen dedizierten physischen WAN-Port, das geht gut über VLANs.

Und dann? Bridge?

Nein, klassisches Routing.

Das Script tut natürlich noch etwas mehr. :) Es berechnet das kleinstmögliche Subnetz, in das neben der öffentlichen IPv4-Adresse noch eine zweite passt. Das Interface, auf dem der DHCPv4-Server läuft wird dann mit dieser zweiten Adresse konfiguriert, außerdem wird sie im DHCPv4-Server als Gateway-Adresse konfiguriert.

Ja, eine Handvoll öffentliche IPv4-Adressen wird dadurch unerreichbar. Praktische Auswirkungen hatte das bisher nie. Das sind ja Adressen, die anderen Kunden des ISPs dynamisch zugewiesen werden und die sehr wahrscheinlich keine Dienste hosten, auf die ich zugreifen müsste.

Das ist ja mal echt interessant, hast du da Links zu?

Ich kann die Konfiguration gerne mal in ein Gist schieben. Würde es aber vorher noch etwas bereinigen und dokumentieren. Besteht konkretes Interesse?

Dann auf der OPNSense eine VIP aus dem Subnetz des Sticks, damit ich auf die WebUI des Sticks komme.

Das wäre in diesem Fall keine VIP, sondern eine normale Interface-Adresse. Denn das eigentliche WAN-Interface ist dann ja ein PPPoE-Device.

Also baut der Switch bei dir die PPPoE Verbindung auf?

Ja richtig, wobei "Router" es bei mir besser beschreibt, da ich das SFP explizit nicht bridge.

Mein Plan wäre, am Switch (CRS305-1G-4S+IN) zwei Ports zu bridgen, den Port, an dem der GPON Stick steckt sowie den Port, der zum Router geht. So dass die OPNSense direkt auf Layer 2 den GPON Stick sieht. Dann Einwahl über die OPNSense.

Das geht natürlich auch. Wobei das nur Sinn ergibt, falls Du auch Verwendung für die anderen Switch-Ports hast. Ansonsten wäre das Standalone-ONT der Telekom (Glasfasermodem 2) oder ein einfacher Media-Converter (1x SFP, 1x RJ45) naheliegender.

Wie geht das? Dann hat doch der hEX die öffentliche IP-Adresse auf seinem PPPoE-Interface?

Über ein eigenes Script. Die guten Scripting-Fähigkeiten sind etwas, was ich bei MikroTik sehr schätze.
Das Script entfernt die IPv4-Adresse vom PPPoE-Interface und fügt sie zum Pool des DHCPv4-Servers hinzu. Für IPv6 ist es noch einfacher, da generiert der DHCPv6-Client ohnehin einen Pool für das erhaltene PD-Präfix. Diesen Pool kann man dann wiederum im DHCPv6-Server verwenden.
Für LTE mache ich es ähnlich (im USB-Port des hEX S steckt ein LTE-Stick).

So habe ich eine saubere Aufgabentrennung: Der hEX S beherbergt die "spezielle" Hardware (ONT, LTE-Modem) und kümmert sich um deren Protokolle (PPPoE, MBIM). OPNsense macht einfach nur DHCP über Ethernet.

Grüße
Maurice

Wäre es möglich, einen kleinen Switch wie den Mikrotik CRS305 quasi als "externes Gehäuse" für das SFP-Modul zu verwenden?

Klar, falls Du ohnehin einen Switch mit SFP-Ports hast, dann kann das GPON-SFP auch da rein.

Bei mir steckt es in einem kleinen MikroTik-Router (hEX S), der zum einen als Switch dient und zum anderen als PPPoE-Offloader.

"Track Interface" ist legacy. Stattdessen sollte "Identity Association" verwendet werden.

Grüße
Maurice


@Patrick Telekom Business = viel Geld für schlechtes Peering, oder?

Das ist bei mir genau so konfiguriert. Bei Services: Router Advertisements unter Recursive DNS Servers (RDNSS) steht eine ULA. Funktioniert einwandfrei.

Da bei dir zudem mehrere Dienste betroffen sind scheint das eher ein individuelles und übergreifendes Problem zu sein. Eher nichts was spezifisch etwas mit radvd zu tun hat.

Grüße
Maurice

Warm werden sie, ja. Mein Zyxel PMG3000-D20B liegt dauerhaft über 60 Grad (ohne aktive Kühlung).
Dennoch hat diese Lösung ihre Vorteile (platzsparend, weniger Kabel, ein Netzteil weniger) und hat sich bei mir bewährt. Kompatibilitätsprobleme zwischen SFP und NIC sind aber wohl in der Tat häufiger als bei "normalen" SFPs.

OPNsense ist das übrigens völlig egal, aus dessen Sicht ist das einfach nur Ethernet (ggfs. mit VLAN und / oder PPPoE).

Falls es bei der Telefonie ausschließlich um DECT geht, dann würde ich eine dedizierte IP-DECT-Basis empfehlen. Die gibt es gebraucht sehr günstig, wahlweise auch mit PoE und sie sind  wesentlich stromsparender als jede Fritzbox.

Grüße
Maurice

Geht es um RDNSS in radvd?

Grüße
Maurice

As promised, I tested again, performed packet captures and looked at the dhcp6c log.

WAN 2 works fine.

For WAN 1
- with Rapid Commit disabled, there is a Solicit from OPNsense and an Advertise from the DHCPv6 server, but OPNsense then doesn't send a Request.
- with Rapid Commit enabled, there is a Solicit from OPNsense and a Reply from the DHCPv6 server, but OPNsense doesn't seem to process the reply.

In both cases, the dhcp6c process for WAN 2(!) logs "skipping unrelated packet (interface 1)".

So it seems that messages received on both interfaces are all delivered to the same dhcp6c process (WAN 2 in my case), which then of course can't find a matching interface in its config for messages received on WAN 1.

How do you deliver inbound DHCPv6 messages to the correct process in the first place? Do the dhcp6c processes bind to distinct sockets?

Cheers
Maurice

I use BIND as the authoritative DNS server for my home network and would be willing to give this a quick test. But it seems the OPNsense BIND plugin doesn't support DDNS, or does it? If not, would it make sense to add this?

Cheers
Maurice

OPNsense 26.1.4 aarch64 packages and sets released.

Here's the isolated change (will apply to a clean 26.1.3/4)

Applied the patch to a clean 26.1.4 and rebooted.
WAN 2 (IA_NA only) worked, WAN 1 (IA_NA + IA_PD) failed (no address, no prefix).
Rebooted again, same result.
Rebooted a third time, now both WANs were back up.
WAN 2 seemed to renew fine, but WAN 1 didn't seem to renew. vltime is 300 seconds for both, so after 5 minutes WAN 1 was down again.
Rebooted again, back at WAN 2 works, WAN 1 fails.

So WAN 2 (IA_NA only) seems fine, but WAN 1 (IA_NA + IA_PD) very inconsistent.

Had to roll back for now because while I'd love to procrastinate more by digging deeper, I really should be doing other stuff now. :)
Will report back with more details another time.

Deleting an interface can negatively affect the default ID generation.

Agreed, making the IAIDs persistent (create them once and then save them in the config) would be beneficial.

Embedding the DUID into the configuration also has some benefits for maintenance regardless of multi-WAN.

Agreed, but don't we already do this? Or only if you explicitly create a DUID in Interfaces / Settings (which I always do)?

Cheers
Maurice

Because they are purely random and wrong.

Random yes, but wrong? I'm not aware of any RFCs requiring IAIDs to have semantic meaning or structure. Any 32-bit unsigned integer is fine.

I don't mind another look or proposal.

Just keep in mind that changing IAIDs can break existing setups. If DHCPv6 static bindings are configured on the upstream DHCPv6 server, an IAID change can cause a mismatch. I recently had that issue in the real world when OpenWrt changed their IAID calculation logic.

But that only matters for IAID+DUID pairs when the multi-WAN connections are going to the exact same server.

Which is not that uncommon, e. g. if you have two lines from the same ISP. Also, duplicate IAIDs (in the context of a given DUID and IA type) are a clear violation of the DHCPv6 specifications (RFC 9915), which I think we shouldn't do for no good reason.

I must admit the IAID changes are not for multi-WAN and we can test without them to go forward in 26.1.x regardless.

I agree, it's a good idea to split these two issues.

Let me prepare a patch for that.

I'll be happy to test it.

Sure, I'll try to reword.

Thanks a lot!

There isn't a strong demand, but with multi-dhcp6 it's a possibility to leverage.

I have no strong opinion about multiple DUIDs. While it doesn't seem intuitive (a DUID literally Uniquely IDentifies a Device, not a DHCPv6 client instance), I see no harm in it. And there might be use cases where it's actually helpful.

Cheers
Maurice


@demyers

At the risk of going off topic

Please don't, this is a CFT.