Messages

DNSMASQ + radvd is my go to setup.  It's a bit complex, but has the added benefits shown at the bottom of this copied + pasted post from the 26.1 release subforum:

I'll use fd00::/64 as my sample ULA prefix for this example, sub in your prefixes as you see fit

1.) Set a ULA Virtual IP with a /64 on the interface(s) where you want ULA stable addressing (eg: fd00::1/64; fd01::1/64 etc.).  Reboot so that the IPs are correctly applied to your interfaces.  I ran into an issue where rebooting was the only way to get this to apply correctly.

2.) Set RADVD to "assisted", configure other options as you see fit; set router advertisement prio to "high" in radvd

3.) In DNSMASQ set up a DHCP range for your interface(s) as shown below.

Interface: Your interface for the ULA assignment (eg: where the virtual IP is set).
Start Address: Set the ULA Prefix + Start address of your desired range (ex: fd00::1000)
End Address: Set the ULA Prefix + End address of your desired range (ex: fd00::2000)
Constructor: None
Prefix Length: 64
RA Mode: ra-names
RA Prio: Normal

4.) Reboot your clients to force soliciting new addresses if needed.


Set the rest of the settings for the lease time etc. as needed for your environment.  The net result is as follows:

1.) My clients receive only SLAAC GUAs.  The prefix assigned by my ISP is in practice not stable, thus DHCPv6 is not a great client option for the GUA.  I also prefer radvd for announcements as it also sends a shutdown, deprecate and remove route announcement if a prefix changes.  The shutdown, deprecate announcement and remove route options are configurable in the advanced settings of radvd per interface.  Note that it is also possible to configure DHCPv6 for both the ULA and GUA.  However, given most ISPs GUAs are not stable, I went with the route described in this post.

2.) My clients also receive a SLAAC ULA and, if client is able, a DHCPv6 ULA.

3.) Local name resolution for IPv6 will only return ULAs.  A lookup of a local client will return either the SLAAC IP, the DHCPv6 IP, or both.

4.) Set DNS forwarding for your interface's domains in Unbound to "forward first" to your interface's IP port 53053 More info here: https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration for configuring unbound forwarding to DNSMASQ.

Note: Enabling both SLAAC and DHCPv6 addresses for the ULA range covers all bases for clients' quirks to get at least one ULA address registered in DNS.  For example, Apple devices prefer a "secure" SLAAC-generated IP which cannot be registered via ra-names, but the DHCPv6 address is registered since that is assigned by DNSMASQ.  Some of my containers and other clients etc. are only SLAAC and will probably stay that way, therefore SLAAC addresses are registered in DNS for these clients and able to be resolved.

End result:

No messy unbound restarts.  All local DNS is managed by DNSMASQ via an unbound forward; all Internet-facing DNS is handled by unbound.  Clients have a stable prefix for local IPv6 addressing and a proper GUA for accessing the public Internet.  IPv4 is also covered: static and dynamic leases are both registered in DNSMASQ.  All bases are covered!

I performed a reboot.  WAN has the new stable privacy address, other interfaces are still on the MAC-based addresses.  sysctl was confirmed set in tunables before reboot and other interfaces have "STABLEADDR" in the nd6 options.

Interesting, I also see "STABLEADDR" set on the nd6 flags for my non-WAN interfaces. These interfaces are still generating MAC-Derived addresses, even with the new sysctl set. Is there a sort of hard-coded reason for this behavior?

It's a new feature changing and potentially breaking existing installations, so it's not enabled by default. Create this tunable in System > Settings > Tunables and reboot: net.inet6.ip6.use_stableaddr=1

I had set it and reboot after my prior post, still seeing the MAC-derived addresses.  I'll give it another reboot over lunch just in case I didn't get the timeline right.

I am seeing the new behavior already on WAN, however.

Interesting, I also see "STABLEADDR" set on the nd6 flags for my non-WAN interfaces. These interfaces are still generating MAC-Derived addresses, even with the new sysctl set. Is there a sort of hard-coded reason for this behavior?

@espenu - I think I have found a close enough solution after a bit of trial and error.  I wanted a similar home setup with stable v6 and v4 addressing so win win!  I use unbound for resolution and forward local network DNS queries to DNSMASQ.  Here's the basic steps:

I'll use fd00::/64 as my sample range for this example, sub in your Prefixes as you see fit

1.) Set a ULA Virtual IP with a /64 on the interface(s) where you want ULA stable addressing.  Reboot so that the IPs are correctly applied.  I ran into an issue where rebooting was the only way to get this to apply correctly.

2.) Set RADVD to "assisted", configure other options as you see fit; set router advertisement prio to "high" in radvd

3.) In DNSMASQ set up a DHCP range for your interface(s) as shown below.

Interface: Your interface for the ULA assignment (eg: where the virtual IP is set).
Start Address: Set the ULA Prefix + Start address of your desired range (ex: fd00::1000)
End Address: Set the ULA Prefix + End address of your desired range (ex: fd00::2000)
Constructor: None
Prefix Length: 64
RA Mode: ra-names
RA Prio: Normal

4.) Reboot your clients to force soliciting new addresses if needed.


Set the rest of the settings for the lease time etc. as needed for your environment.  The net result is as follows:

1.) My clients receive only SLAAC GUAs.  The prefix assigned by my ISP is in practice not stable, thus DHCPv6 is not a great client option for the GUA.  I also prefer radvd for announcements as it also sends a shutdown, deprecate and remove route announcement if a prefix changes.  The shutdown, deprecate announcement and remove route options are configurable in the advanced settings.

2.) My clients also receive a SLAAC ULA and, if client is able, a DHCPv6 ULA.

3.) Local name resolution for IPv6 will only return ULAs.  A lookup of a local client will return either the SLAAC IP, the DHCPv6 IP, or both.

Note: Enabling both SLAAC and DHCPv6 addresses for the ULA range covers all bases for clients' quirks to get at least one ULA address registered in DNS.  For example, Apple devices prefer a "secure" SLAAC-generated IP which cannot be registered via ra-names, but the DHCPv6 address is registered since that is assigned by DNSMASQ.  Some of my containers and other clients etc. are only SLAAC and will probably stay that way, therefore SLAAC addresses are registered in DNS for these clients and able to be resolved.

Out of morbid curiosity I set up DNSMASQ with SLAAC as the mode with the IP range of my ULA ffd0::1000 to ffd0::2000 (ULA truncated).

I'm fairly certain that it won't make a difference but a ULA is currently defined in the range of fd00::/8

That was a typo on my part, thanks for the nudge.  The ULAs I have defined are indeed correct and sane.  I'll leave the original post as is regardless.

While you can syntactically do that and maybe the different RAs even get send out, I would not have expected it to work, because RAs are broadcasts, so they reach all clients. The mode flag determines if the clients should ask for DHCP offers. So, the clients will probably not request DHCP addresses once they see an RA that explicitely forbids them to.

I doubt that they would do that depending on specific ranges.

Reaching all clients is fine and likely with OP is after (me too!).  The use case here is to have clients assign a ULA via both DHCPv6 & SLAAC, with SLAAC alone for GUA.  I can see the use case here given that ISPs do not keep GUAs and therefore internal addressing stable.  Other issues of course persist with client preference. 

I managed to have this same setup working with kea a while back and may resume it with one of the 3rd-party (non repo) ddns plugins that work with unbound to register leases.  Keeping BIND happy was just too much effort.  Here's the little plugin: https://github.com/JameZUK/os-kea-unbound/

Maybe dnsmasq can do it. You can configure different RA pools on the same interface with different flags from what I can see.

But I never tested that.

Out of morbid curiosity I set up DNSMASQ with SLAAC as the mode with the IP range of my ULA ffd0::1000 to ffd0::2000 (ULA truncated). I also set up ra-stateless for :: 

Clients only seemed to get the slaac-generated IPs; the dhcpv6 ULA range did not assign a DHCP ULA address in the range above.

Happy to be wrong here in case I did a misconfigure, but manually-entered ranges including a prefix appear to be ignored for the use case of only defining a ULA range for dhcp. ::1000 to ::2000 without the prefix worked as expected, but only for the GUAs.

I'll double check my work and maybe open a bug report if needed, as the info tip for defining IP ranges does show a prefix (if defined on an interface of course) as a valid input for an ip range.

I use it with M-Net. I know that Telekom and their resellers does not work with 1500 bytes MTU.

Good to know; I'm also on M-Net FTTH.  Looks like I have some homework tonight and can unwind my MSS workaround in the same go.  Thanks for the quick reply!

*EDIT* With a bit of trial and error, I am working at MTU 1500 as expected. on my PROXMOX + opnsense setup  My steps in a nutshell:

PROXMOX:

1.) Set my dedicated "WAN" bridge (vmbr1 in my case) and its associated single interface (enp2s0 in my case) to 1512 MTU; reboot


OPNSENSE:

1.) (Interfaces > Assignments) Enable interface vtnet0 (which is mapped to WAN bridge vmbr1 in PROXMOX); assign it the name WAN_VLAN_PARENT; set MTU of WAN_VLAN_PARENT to 1512
2.) (Interfaces > Assignments) Enable interface vlan0.40 (which is for me VLAN40 for my ISP M-Net mapped to vtnet0); assign it the name WLAN_VTNET40; set MTU of WLAN_VTNET40 to 1508
3.) (Interfaces > Devices > Point-to-Point) Set MTU of PPPoE interface pppoe0 to 1500 (under advanced options)
4.) REBOOT opnsense (important!)

Note: The WAN interface in opnsense may still show that the "calculated MTU" remains 1492; ignore this as you've overriden the MTU on pppoe0! Test the config with a site like http://pmtud.enslaves.us/ -- IPv4 should show a MTU of 1460 and IPv6 an MTU of 1440 if the above steps were configured correctly.

To future readers:  your interface names (italic) above across your virtualization host and opnsense may vary, please remap accordingly!  Follow the notes in the guide in the OP if you are on a bare metal install as that takes out the complexity of configuring the MTU of the virtualization host.

With this setup I no longer need my MSS clamping workaround on my WAN interface for DNSMASQ; it's as if I have a "normal" ISP without PPPoE.  Reiterating OP's post that this only works with select ISPs and especially NOT telekom or telekom-hosted ISPs like 1&1, O2, etc.

@meyergru With which ISP in Germany are you utilizing the sortachonky-mini-baby-jumbo Frames?

I'm also oddly honored to have my post made it in the pppps of the OP :) Credit goes to the post I found on github for the workaround.

Closing this out with a fix if you missed it:

Validate your MTU settings.  DNSMASQ does not seem to configure MTU correctly if you are using PPPoE on WAN.  RADVD does not have this issue.  I set the "MSS" of my WAN interface to 1492 (PPPoE standard) and IPv6 now works flawlessly with DNSMASQ as my Router Advertisement service.

Thanks for this post. I had ISC dhcp working fine with Ipv6 but I saw that it was advised to go to Dnsmasq. After a week bad DNS (some sites like this forum even got 'timed out') I switched back to the normal Router advertisements and everything worked instantly.

Necrobumping this thread as I stumbled on nearly the exact same issue.  For me DNS didn't seem to be the issue as the behavior was the same regardless of if using local DNS resolution or a public resolver.  The issue I found was TLS connections not establishing as expected for IPv6.  Moving back to kea + router advertisements is my immediate fix, but getting to the root of why DNSMASQ didn't play nice would be great.

I'll also crosspost my Reddit post for anyone in the future who may stumble on this: https://www.reddit.com/r/opnsense/comments/1r9uxs0/odd_ipv6_traffic_behavior_dnsmasq/

Affects me on opnsense 26.1.2_5 on top of proxmox