Messages

@Monviech Exactly, "Upstream Gateway" is a preference setting, not a "this gateway will always / never be upstream".
Having two preference settings (numeric "Priority" and binary "Upstream Gateway") has always been a bit confusing.

But if you want a default route that is configured as a gateway to stick only checking that as upstream (defaultgw) will do the job so nothing else will create a different gateway.

That's a little off topic here since the OP doesn't want the default route to be set by a gateway at all, only by BGP. But while we're at it: Marking a gateway as upstream doesn't reliably prevent non-upstream gateways from becoming the default gateway.

I've had a situation with three gateways, 1 and 2 marked as upstream and with gateway monitoring enabled, 3 not marked as upstream. The intention was default gateway switching between gateway 1 and 2 (failover), while using gateway 3 only for some specific static routes.

This worked as long as gateway 1 and / or 2 were up. But when both went down, gateway 3 became default (which should never happen). The only way to prevent this was marking gateway 3 as "down".

If anything has changed in this regard, I'd be happy to learn about it.

If the gateway is needed for static routes or policy routing, keeping it enabled but marking it as "down" is what worked for me. Not sure whether this (still) is best practice though.

@franco Doesn't unchecking "Upstream Gateway" only lower the priority? From my experience, this doesn't prevent a gateway from becoming the default. Has this changed?

@mooh These firewall rules have nothing to do with the default route in the routing table.

Cheers
Maurice

There are many nuances in NAT64, e. g. how exactly ICMP messages are translated between versions (which is quite complex because the payload has to be translated, too).

apalrd (new maintainer of Tayga) did a comparison of different NAT64 implementations:

https://youtu.be/WlQH8KubgiA

Which NAT64 implementation were you using?

As far as I remember, Tayga and Jool. I most certainly performed some packet captures and seem to recall that the phone didn't even try to use IPv6 for VoWiFi. There wasn't anything after the DNS lookup for the ePDG. I suspected that the VoWiFi stack of my phone didn't even support IPv6.

But it's been a while and the details are a bit foggy, so you might want to repeat these tests.

@Monviech There are zero user configurable options for VoWiFi, other than on and off. That's pretty much a black box deep in the phone's software stack. I seem to remember that the core functionality is even provided by the SoC, not Android itself.

There no longer is a global "enable blocklists" setting in Unbound since the business implementation was merged into the community version in 25.7.8.

If you want to use the Q-Feeds blocklist exclusively, does this mean you only have to enable "register domain feeds" in the Q-Feeds settings and don't have to configure anything in Unbound?

Looks like an ISP issue, agreed. Have you tried reverse trace routes, too (e. g. from public looking glass services to your own system at home)?
RIPE Atlas is also a good tool to identify ISP-wide issues.

Getting past level 1 support can be challenging. When an ISP I once was with had routing issues, I might have had success with looking up an email address of their NIC an emailing them directly. They didn't respond, but the issue was fixed soon after.

Don't make it sound like a support request. Just a brief heads-up "hey, you have this exact routing issue, this is how to reproduce it". The correct people might read it and silently fix the issue.

Cheers
Maurice

I've experimented with WiFi Calling over NAT64 in the past and never got it to work. If anyone had success with this (with any NAT64), I'd be interested. But I'd say it's up to the MNOs to add IPv6 support to their ePDGs.

The new pf 'af-to' feature in FreeBSD 15 indeed makes native NAT64 in OPNsense realistic in the near future. From a quick look, it seems that's what pfSense uses, too (by using FreeBSD prerelease code?). But I'm not very confident this solves the WiFi Calling use case (although I'd be happy to be proven wrong).

@Monviech For general purpose networks, directly switching from Dual Stack to IPv6-only without NAT64 seems unrealistic anytime soon. Some IPv4-only services will be around for many, many years. So IPv6-only with NAT64 is a sensible intermediate step. Among other reasons, it eliminates the management and troubleshooting overhead of Dual Stack while maintaining compatibility with legacy IP.
If you're more conservative, you can go Dual Stack with IPv6-only preferred first, but this requires NAT64, too.

@patient0 apalrd has mentioned being an OPNsense user, but I'm not sure whether he uses the OPNsense Tayga plugin or Tayga on a dedicated Linux system.

Cheers
Maurice

The screenshot shows a packet passing the nat64 interface. That's an internal virtual interface connecting Tayga to the kernel. In this context, "let out anything" means "allow the kernel to send packets to Tayga".

Do you only see such matches for ICMPv6? The default rules allow certain inbound ICMPv6 types on all interfaces, like Destination Unreachable or Time Exceeded.

Do you maybe use Tayga as a CLAT?

Cheers
Maurice

By default, it shouldn't be accessible from the outside. External access would require creating an allow rule on the WAN interface. So you might want to check your firewall rules.

Cheers
Maurice

I've now set hw.vtnet.csum_disable=0 on two OPNsense instances with vtnet interfaces (one amd64, one aarch64).
Will report back with anecdotal observations (remind me if I forget because everything works).

Code Select Expand

options=ec07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS>
Cheers
Maurice

It's still disabled in the OPNsense default tunables. You can change this in System: Settings: Tunables.

Cheers
Maurice

Are you talking about local overrides created by DHCP? Or a real local zone?
For the latter, neither dnsmasq nor Unbound are good options. These aren't authoritative DNS servers. BIND is and it's available as a plugin for OPNsense.

Cheers
Maurice

@neel I had a look: You currently can't build USB installer images (make serial / make vga) on aarch64. The build script wants to add a protective MBR to the image, but this only exists on amd64.

But building an iso image (make dvd) is possible, this has explicitly been enabled for aarch64.

OPNsense 25.7.9 aarch64 packages and sets released. Includes ndp-proxy-go 0.3.0.

[Update 2025-12-12]
Hotfix 25.7.9_7 released.