Messages

If SLAAC is in play the addresses can be static too since they can be EUI-64 derived. SLAAC depends on the client configuration as well, like deactivating privacy extensions and other randomized SLAAC generation behavior, and only allow EUI-64 (or RFC 7217 stable addresses).

privacy/temporary addresses (RFC 4941 / RFC 8981) are entirely a host decision

That would require full admin access to all clients though (I mean, I do have that, but it might not always be the case).
I'm not trying to be difficult (not intentionally at least 😜), it's just that Opnsense is such a great system and it would be so great if it was possible to handle this type of setup (which I think is a completely valid use case), especially since the underlying systems actually support it and it's "just" a UI limitation.

I understand that it might be a narrow use case so no one wants to spend dev time fixing it, and that's fair. I will then just have to find a different approach to the whole stup, but at least I've raised the question 😊.

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.

I read somewhere that the same limitation was also present in the Dnsmasq RA, but I haven't actually tried it the way you describe. I will see if it's possible as soon as I have time to sit down and experiment.
Thanks.

Maybe not so different, and to (finally ;) ) answer your question, I did briefly consider NPT but since that relies on the subnet sizes being identical (LAN and ISP), I've decided it to be better to go NAT66. That way I don't need to care about what prefix size the ISP hands me, so an ISP change would be fully transparent and not even require any configuration change. I feel NAT66 is the superior choice for this type of setup, even if it's unusual and commonly frowned upon due to what feels like ideology these days. :)

There is a very strong dogma that NAT66 is the devil itself (check out ipv6 reddit for example, they literally excommunicate people who even think about NATing IPv6).

In my opinion it just solves the same issue as NAT44 did, delegating the ownership of an IP address to a central device like a router. This is useful for Multi-WAN, dynamic DNS, VPN setups etc... and other kind of more specialized setups.

NPTv6 is harder to use, since e.g. in a SLAAC only network your router doesn't own the non-translated addresses and won't respond via NDP for them. There are ways to fix that but it's way more brute force than just using NAT66 instead.

I'm not quite in the camp of NAT66 being the devil. But it kind of breaks the intention of IPv6, and since my goal here is to have a working full dual stack while also learning proper IPv6, NAT66 feels like kind of a cheat.
By all means, it has its uses, it just doesn't align will my goals for this setup.

As I have understood it (and I'm still learning so I might be misunderstanding), the reason my setup doesn't work is due to the limitation in the Opnsense UI where setting up RA has to be done per interface, and it can't be tailored per prefix. So in this case both NPTv6 and NAT66 would be a workaround for an incomplete implementation (because it seems to have been an intentional design and not a bug).

(again) ULA + NPTv6 seems like the obvious solution if you want to use ULAs internally with a dynamic GUA prefix for internet access. Have you even considered it? Hacks are likely to come back and bite you later...

Sorry for the late reply to this post. I feel like NPTv6 itself is a hack though. Or, maybe not a hack, but it's still an address translation and veering away from the pure IPv6 setup that was my goal for this setup.

With IPv6 you can set any number of addresses you wish, so it should be possible to add the ULAs in addition to the SLAAC GUAs. The only issue is that the GUI doesn't expose this feat (at all: even in the static configuration, it allows only exactly one IPv6 address to be set). I'm looking into disabling LLA autogeneration and instead manually assigning LLAs to match the ULAs so I can see which machine is burping in the logs without translating MACs all the time. But I need to enter two addresses for this to work though the GUI. Command line or script works of course, but it's a GUI-based system so...

You can add additional ULAs as virtual IPs on each interface.

Why not using good, old IPv4 for internal things?

I am also fond of that, see: https://forum.opnsense.org/index.php?topic=45822.0 for an in-depth discussion.

I get that, and technically I don't NEED IPv6 for internal communication.
It's an interesting exercise in understanding IPv6 better. As I understand it there is nothing "wrong" with my approach here, which is why it's frustrating that it almost works, but not quite.

I've finally had a chance to properly read through the thread you linked to, and there is a statement that I can't get to match with what I'm seeing from post 72:
"That is were ULA might be helpful. Then again, with dual stack, they will not be used when an IPv4 DNS entry exists."

But on my Debian machines it seems like ULA is prioritized over IPv4.
At least if I ping a host with both defined in DNS it's the ULA that's used.

Why not using good, old IPv4 for internal things?

I could, but in the process of learning IPv6 better I wanted to run fully dual stack in the homelab. I don't think what I'm trying is too far outside of normal IPv6, so it should work.
If I'm doing something wrong I would like to learn what the correct way is.

In all my VLANs my clients currently get a GUA address using SLAAC.
But for internal server communications I don't want to risk a prefix change from my ISP to break internal communications.
So, I've settled on using DHCPv6 to give out ULA addresses. Each server is given a dedicated address added to its host entry in dnsmasq.
Opnsense is given a ULA in each subnet as a virtual IP on each interface. In Router Advertisements the mode is set to assisted.
This partially works, as the clients get both a SLAAC GUA and the DHCPv6 ULA. However, since it's not possible to set RA modes per address, only per interface, I also get a ULA SLAAC address.
The extra address wouldn't have been a big deal if it wasn't for the fact that the servers use the ULA SLAAC as their source address when communicating across VLANs.
Because of that, my firewall rules, which rely on the hostname entries, kind of break.

The only "solutions" I've found are:
- Use the ULA SLAAC for source in firewall rules, but this is messy and the SLAAC may be using privacy extensions so the address is not deterministic (which is why I wanted DHCPv6 in the first place).
Disabling privacy extensions also makes the GUA EUI-64 and therefore exposes the MAC (not a deadly critical issue, but I want to avoid it). It also requires custom configuration depending on server OS, which I don't like.

- Use the whole network prefix as the source in firewall rules. This is what I currently do, but it makes my rules much "looser" than I would like.

The best solution would be if I could only set the RA A flag to only be used for the GUA prefix. But as I understand it that's not possible in Opnsense because settings apply to all addresses on the selected interface.
Or are there ways to do this that I just haven't found?
The "for all addresses in the interface" approach is also annoying with DHCPv6, because if I use the constructor and only specify the end addresses for the range, it will give out DHCPv6 for both GUA and ULA, when I only want the ULA. Specifying the whole range addresses solves this of course, but it's still a bit annoying.

Are there solutions to this issue? Am I just thinking about the whole thing in the wrong way?

We are having some issues with DNS records getting lost when using DHCP and "Register DHCP leases".
The problem is that if the clients have been off for a while, the lease expires and the DNS record is gone (as expected). When those PC's are then started again, they get a new DHCP lease, but no DNS record. Restarting the DNS service makes them all appear again.

We were first using Unbound DNS, and then tried switching to Dnsmasq in case the issue was in Unbound.
Both Unbound and Dnsmasq are set up with both "Register DHCP leases" and "Register DHCP static mappings".

If all PC's are set to use static DHCP lease this problem goes away, so we can work around it, but we would prefer to be using dynamic lease.

At the moment 24.1.2 is in use, but we have seen this problem since the system was set up in September.

Our system has multiple opnsense routers which all have this issue, and none of them are internet facing. They all use another opnsense edge router for internet access.

Any idea what could be causing this?

Any ides on how I should go forward to get this working again?

Also, it does actually seem to be mentioned before:
https://github.com/opnsense/core/issues/3531#issuecomment-517983520

Any ideas of what could have happened? I haven't changed any settings, and it was previously working fine.
I don't have any systems rely on IPv6, so I don't know how long since it stopped working.

Is there any more information I can provide to see where the issue might be?

Has something happened to 6rd support? I'm now on 19.7.3 and I can't get it to work any more.
It worked fine before, but I don't think it has worked at all for me on 19.7.

Pinging ipv6.google.com all I get is: ping6: UDP connect: No route to host