Messages

So I'm not sure I gain any separation by using a dedicated loopback interface for redirects over just assigning a ULA VIP to the normal loopback.

Additional loopback interfaces are useful for running multiple services on the same port, but on different IP addresses. Some services only allow you to specify the interface they bind to, but not a specific IP address. So you need one interface per service / IP address.

If you just need additional IP addresses (e. g. as NAT redirect targets), I see no benefit in additional loopbacks and would indeed use VIPs.

Cheers
Maurice

Was meinst Du mit "Interface eintragen"?

Services: Router Advertisements
Falls es dort einen Eintrag für das FRITZBOXWAN-Interface gibt, diesen löschen.

Falls nicht, dann:
Interfaces: [FRITZBOXWAN]
IPv6 Configuration Type auf Static IPv6 stellen (und eine Dummy-Adresse eintragen, z. B. 2001:db8::1/64).
Nun wieder zu Services: Router Advertisements und den Eintrag für das FRITZBOXWAN-Interface löschen.
Wenn Du schon dabei bist: Prüfen, dass weder Kea noch ISC noch Dnsmasq auf dem FRITZBOXWAN-Interface aktiv sind.

Abschließend das FRITZBOXWAN-Interface wieder auf DHCPv6 umstellen.

Eventuell wurde opt10 / vtnet4 früher mal anderweitig verwendet und bei der Umwidmung zum WAN-Interface wurde dann radvd (und ggfs. weitere Dienste) nicht korrekt deaktiviert. Und rtsold + radvd auf dem selben Interface geht quasi zwangsläufig schief.

Grüße
Maurice

Auf dem WAN-Interface darf definitiv kein radvd laufen, da ist irgendwann etwas mit der Konfiguration durcheinander gekommen.

Stelle das WAN-Interface mal vorübergehend auf Static IPv6, dann kannst Du die Router Advertisements deaktivieren. Anschließend wieder auf DHCPv6 umstellen.

Alternativ die config.xml manuell bearbeiten.

Grüße
Maurice

Looks like you may have somehow managed to enable radvd on your WAN interface? This should be mutually exclusive - you can either run rtsold (on WAN-type interfaces) or radvd (on LAN-type interfaces), but never both. Check your config.xml as well as /var/etc/radvd.conf.

Cheers
Maurice

[edit] Sorry, bin mit den Sprachen durcheinander gekommen. Ich sollte um die Zeit vielleicht nicht mehr posten. 🥱[/edit]

ich vermute, ich bekomme kein Prefix von der FritzBox

Der Vermutung kannst Du nachgehen, indem Du das Log von dhcp6c anschaust (System: Log Files: General, ggfs. Debug-Logging in Interfaces: Settings aktivieren).

Grüße
Maurice

OPNsense 26.1.6 aarch64 packages and sets released.

[Update 2026-04-28]
Hotfix 26.1.6_2 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