Messages

OPNsense 26.1.6 aarch64 packages and sets released.

Consumer routers don't let you create an arbitrary number of subnets or manually configure subnet IDs at all. If all you have is one LAN and maybe a guest network, it's easy to handle a dynamic PD size. Just use subnet ID 0 for the LAN and 1 for the guest network. If you only get a /64, disable IPv6 for the guest network (or enable an NDP proxy).

We shouldn't do that level of automation in OPNsense. But the current workflow isn't ideal either. Many ISPs don't document their PD size. So you have to go to Interfaces / Overview, click the WAN interface's magnifying glass, scroll down to "Dynamic IPv6 prefix received" and then configure the PD size displayed there in the WAN interface's DHCPv6 client settings.

Franco, I think we once discussed the idea of a big fat warning somewhere in the GUI when the configured PD size doesn't match the actual PD size. I still think that would be a good idea.

Or maybe go one step further and actually change the config based on the actual PD size (optionally of course)?

Cheers
Maurice

In my mind, this should be determined from the DHCP response, so I shouldn't have to configure it statically.

A good idea in theory (and some / most consumer routers do that), but for more advanced setups you really need to know the PD size in advance. For example, when configuring the subnet IDs of your LANs, you need to know how many bits are available. Let's say you configure a subnet ID 0x10 but then only get a /60... Things will break.

Cheers
Maurice

I like to avoid YouTube whenever I can when it comes to this kind of stuff : Reading about it is more my style :)

https://docs.mono.si/gateway-development-kit/hardware-description
https://docs.mono.si/tutorials/development-set-up (note the references at the end)

So it's like my old Router with MIPS SoC like I thought.

Pretty sure that didn't run OPNsense. :)

Can you at least mix both things without the need to disable any of the Offloading Features first ?

Not sure what you mean by "mix both things". And it's all about the offloading, disabling it wouldn't make sense.

So with that kind of setup the issue with the FreeBSD Bootloader needing an upgrade from time to time can be ignored, right ?

Correct. That's not the reason why it was implemented this way, but I guess it could be considered a positive side effect.

Are there any AARCH64 Mainboards out there that can run FreeBSD or simply OPNsense without any big issues ?

Yes, this one. :)
(But seriously, I don't have any other recommendations. Other aarch64 SBCs which can run OPNsense might be nice for hobby projects, but not for serious networking.)

Since you are our AARCH64 Releases guy and all :)

I've only used it on VMs until recently. Gateway changed that.

The SFP+ cage is there, but how much latency does the RJ45 transceiver add?

Essentially none (less than a microsecond?), that's just a PHY.

I really recommend Tomaž's videos for the hardware offloading deep dive. He's the expert on this, I'm not.

But where does one put this SoC based on it's performance ?

It has 4 Cortex A72 cores. But most packets never touch these cores.

And why suddenly use Offloading while it's always recommended to disable all of it for both OPNsense and pfSense ?!

What you're probably thinking of is offloading basic packet processing like checksums to the NICs.

Gateway doesn't have NICs in the traditional sense. The PHYs connect directly to the SoC, which handles routing and other frame and packet processing (VLANs, NAT, PPP, ...) in dedicated hardware. This means routing at wire speed with essentially no CPU load, like on a switch. The CPU cycles are available for other stuff that can't be offloaded.

The 64 MB NOR flash is for U-Boot and a small recovery Linux. The main OS (originally OpenWrt, now OPNsense) is installed on the 32 GB eMMC.
The OPNsense image we've just made available uses GPT and ZFS, but Gateway currently doesn't use FreeBSD's UEFI kernel loader. Instead, U-Boot loads the kernel directly.

Keep in mind that this is ongoing development and things may and probably will change in the final production version.

Cheers
Maurice

Yes, I have one and it does indeed run OPNsense. Hardware offloading is supported and really sets it apart from anything I've seen before. And yes, it can offload connections which are firewalled by pf. Pretty impressive.

I recommend watching Tomaž's latest video on YouTube.

Cheers
Maurice

Full disclosure: I've been contracted by Mono to maintain their OPNsense update server.

OPNsense 26.1.5 aarch64 packages and sets released.

You can upload an OPNsense VM image, e. g. using the Horizon web interface: https://horizon.cloud.ovh.net/project/images
This can then be selected when creating an instance. No need for an interactive installation or bootstrap.

Cheers
Maurice

@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.