[SOLVED] Router Advertisement Question

Started by ProximusAl, July 21, 2025, 02:44:43 PM

Previous topic - Next topic
July 21, 2025, 02:44:43 PM Last Edit: July 21, 2025, 03:31:36 PM by ProximusAl Reason: Marked as solved
I currently use Services->Router Advertisements->LAN in stateless mode to squirt out some IPv6 addresses to my LAN.
Specifically, the key part I need is AdvLinkMTU, which for me is set to 1280, due to the fact I get my IPv6 over Wireguard from a VPS.

I've moved everything from ISC and Unbound to fully use DnsMasq, which works great, but left my RA as above.

As an exercise, I was looking to move my RA to DnsMasq, but stumbled across the AdvLinkMTU issue, which you dont appear to be able to configure.

I haven't got an issue sticking with the current method, but wondered if I was missing a trick here?

If I move it to DnsMasq, the MTU wont be set to 1280......and I don't want to lower my whole LAN, as the above works just fine.

TIA



Just to confirm this worked perfectly.

Thanks....

Now using DNSMasq for DHCP, DNS, and RA.

Sorry, but I'm back again.

It seems that DNSMasq is sending out RDNSS when I dont want it to....:(

Anyway to stop that? I dont want any DNS info sent with the RA.

In the other method it was a checkbox, but struggling to find it in DNSMasq...

Sorry for the trouble....

In DHCP Options, create one like this:

Type: Set
Option6: dns-server [23]
Interface: Any
Value: (you leave this field empty)
Description: Strip DHCPv6 and RDDNS dns server option

That should strip it, empty value DHCP option should do the trick.

If not, please tell me and I'll double check on my end.
Hardware:
DEC740

I *think* that may have done it:

No rdnss option showing now

15:26:32.529712 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::aab8:e0ff:fe02:d25 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 64
        hop limit 255, Flags [other stateful], pref medium, router lifetime 600s, reachable time 0ms, retrans timer 0ms
          prefix info option (3), length 32 (4): fd76:192:168:76::/64, Flags [onlink, auto], valid time 86400s, pref. time 86400s
            0x0000:  40c0 0001 5180 0001 5180 0000 0000 fd76
            0x0010:  0192 0168 0076 0000 0000 0000 0000
          mtu option (5), length 8 (1):  1280
            0x0000:  0000 0000 0500
          source link-address option (1), length 8 (1): xx:xx:e0:02:0d:xx
            0x0000:  a8b8 e002 0d25

Great.

Dnsmasq does some shenanigans here.

It combines the DHCPv6 dns-server option with RA to also send it out as RDDNS option.

So by stripping it, it surpresses the RDDNS option, was my assumption. And I think it was right.

Hardware:
DEC740

It seems fine on iOS devices, but one of my windows devices still has the DNS, even after a reboot.
It's a Proxmox VM so need some digging.

Might need to get wireshark involved here.

Definitely can't see the rdnss in the RA on Linux.

Thank you so much for your help thus far....

Windows might cache it until a reboot its a bit weird there.

Or try "ipconfig -release6"

If you find anything else weird let me know :)
Hardware:
DEC740

Thanks Cedric,

Thankfully a reboot of Proxmox itself seems to have resolved it.

I can only imagine RDNSS got stuck on vmbr0, which is what the windows VM uses.

I truly love OPNsense, and I am so appreciative of your help.

Back again, with hopefully the final piece of the puzzle, and it's a bit technical.
I don't want to get too deep into my config, but it all involves ULA and NPTv6, but the crux of my issue now is this:

With OPNSense->Services->Router Advertisement that RA includes:

route info option (24) (I assume because of the tickbox Advertise Default Gateway)
mtu option (5)
source link-address option (1)

With DNSMasq, it only has:
mtu option (5)
source link-address option (1)

Is there a way in DNSMasq to get the RA to include route info option (24)

Without it, my Linux servers are having a hard time using IPv6. (Because of other ULAs, and source address selection) iOS and Windows are fine.....

The way I do my IPv6 is *far* from ideal, but it is what it is, short of turning it off :)

July 22, 2025, 10:07:57 AM #12 Last Edit: July 22, 2025, 10:12:56 AM by meyergru
It seems DNSmasq does not handle IPv6 routing, to the contrary, the docs for the only two available options say:

Quote--enable-ra
    Enable dnsmasq's IPv6 Router Advertisement feature. DHCPv6 doesn't handle complete network configuration in the same way as DHCPv4. Router discovery and (possibly) prefix discovery for autonomous address creation are handled by a different protocol. When DHCP is in use, only a subset of this is needed, and dnsmasq can handle it, using existing DHCP configuration to provide most data. When RA is enabled, dnsmasq will advertise a prefix for each --dhcp-range, with default router as the relevant link-local address on the machine running dnsmasq. By default, the "managed address" bits are set, and the "use SLAAC" bit is reset. This can be changed for individual subnets with the mode keywords described in --dhcp-range. RFC6106 DNS parameters are included in the advertisements. By default, the relevant link-local address of the machine running dnsmasq is sent as recursive DNS server. If provided, the DHCPv6 options dns-server and domain-search are used for the DNS server (RDNSS) and the domain search list (DNSSL).

--ra-param=<interface>,[mtu:<integer>|<interface>|off,][high,|low,]<ra-interval>[,<router lifetime>]
    Set non-default values for router advertisements sent via an interface. The priority field for the router may be altered from the default of medium with eg --ra-param=eth0,high. The interval between router advertisements may be set (in seconds) with --ra-param=eth0,60. The lifetime of the route may be changed or set to zero, which allows a router to advertise prefixes but not a route via itself. --ra-param=eth0,0,0 (A value of zero for the interval means the default value.) All four parameters may be set at once. --ra-param=eth0,mtu:1280,low,60,1200

    The interface field may include a wildcard.

    The mtu: parameter may be an arbitrary interface name, in which case the MTU value for that interface is used. This is useful for (eg) advertising the MTU of a WAN interface on the other interfaces of a router.

You can still disable RA and go on using RADVD or use Kea/Unbound/RADVD.
Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

Thanks,

The issue I am seeing is as follows:

In my home lab, I get my IPv6 from a VPS over Wireguard on OPNSense.

I am using ULA on my LAN, with NPTv6 to get out to the internet.
I do this almost to depreference IPv6, as most OS will choose IPv4 over an IPv6 ULA. (IPv6 slower link over wireguard, and data caps)

This actually works really well with OPNSense's built in Router Advertisements.

When trying to use DNSMasq, it seems the route info option (24), or lack of, is a critical part of making what I do work.

What was happening last night, was when I started using DNSMasq to advertise, the lack of RIO (24), allows other devices on my network to announce a ULA prefix.
Namely, an Amazon Echo Studio.  It started advertising an fd35: prefix, which gets picked up by my Linux server, which now has both (fd35, and my advertised fd76)
As I mention, iOS and Windows seem to cope with this, but Linux prefers the ULA with RIO (24) as its source address and thus....no access outbound.
Deprefrencing the fd35 address (lft 0), and it then works.

When using OPNSense Router Advertisements, it includes RIO(24), and the Amazon echo, on seeing this, stops advertising its own prefix, and my Linux server starts to work.

As I said, the way I do IPv6 is horrible, but better than not having it at all.

For now, I'm back to using OPNSense RA's, and everything is working.

My head hurts a lot from deep diving tcpdump.....


Yes, with Android devices, you cannot use meaningful DHCPv6 instead, either. Thus, with the lack of support for route options in DNSmasq, you will have to use another RA daemon. So it's either RADVD with DNSmasq's RA disabled or losing DNSmasq in the first place in your situation.

If there ever was a solution to this, it has to be upstream in DNSmasq.
Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+