Messages

radvd 2.20 got released and is present in opnsense 25.1! (ref: https://github.com/radvd-project/radvd/pull/179)

Is there any chance we could get `NAT64Prefix` support for radvd exposed in the opnsense radvd (web UI) configuration?

I've got Tayga installed for NAT64. I noticed that, after Tayga was installed and activated, actions where the opnsense router itself was reaching out to the public Internet (router-originated traffic, not client / transit traffic) was broken. A key example was that package/firmware updates and plugin searches and such were broken. I eventually tracked this down to IPv6 traffic specifically.

With more digging, this turned out to be that the router would select the "IPv6 NAT64 Interface Address" address from Tayga configuration as the source IPv6 address for outgoing traffic. This probably makes some sense, as in my case this I was using something in the doc prefix, as 2001:db8:1:ffff::1. That ends up being the lowest numbered GUA address on system, which is a common enough criteria for source address selection algorithms.

That IPv6 address obviously is not actually bound on the system and isn't Internet-routable, so traffic would leave the box with that source address and never make it back.

Adding a NAT policy for just that "IPv6 NAT64 Interface Address" works, in selecting another local IP address as the NAT target address, but it definitely was a confusing symptom.

Can we perhaps add something into the Tayga docs at https://docs.opnsense.org/manual/how-tos/tayga.html that maybe this should be a ULA or something? Since I'm getting IPv6 addressing via DHCPv6-PD, it's not feasible for me to enter a fixed GUA address in here, for instance. My fix for now has been to dedicated the last /64 out of my /48 ULA range as the "IPv6 NAT64 Interface Address", so that it should not be eligible as a source IP address for talking to GUA resources on the public Internet.

Alternatively, I'm not sure if there is a way to "exclude" the Tayga address from being eligible in source address selection?

[edit: remove; wrong thread]

k, it looks like this was fixed/updated in https://github.com/radvd-project/radvd/commit/17c43bff200bbc1d4786eb917860a79db4f95c2e, with a reference to https://github.com/radvd-project/radvd/issues/143

That's in master, but currently in the v2.20_rc1 tag. So, it's not present in the current 2.19 release. in the meantime, the online published docs appear to reflect that 3*MaxRtrAdvInterval, while 2.19 still does AdvRDNSSLifetime = MaxRtrAdvInterval.

We'll just have to wait for the proper 2.20 release of radvd, from the looks of it.

Ah, gotcha. Thx, I see that now under `/var/etc/radvd.conf`, that AdvRDNSSLifetime and AdvDNSSLLifetime are left empty / unset, not autogenerated explicitly. Thx. I will check over with radvd.

The default AdvRDNSSLifetime and AdvDNSSLLifetime at this point appear to be equal to the MaxRtrAdvInterval. That seems to risk loss of RDNSS and DNSSL if a single RA is lost.

RFC 8106 5.1 (https://datatracker.ietf.org/doc/html/rfc8106#section-5.1) indicates that that the lifetime of DNS options should by default be 3x MaxRtrAdvInterval.

Is it intentional that this is currently equal to MaxRtrAdvInterval instead?

Add me as another interested party for this.

It does look, though, like that is still only present in an RC release (v2.20_rc1):
https://github.com/radvd-project/radvd/blob/master/CHANGES

The PR was merged to master on 2022-07-08:
https://github.com/radvd-project/radvd/commit/a6460662c6ac2b13307a8977ef068825b66fbce0

The most recent main release for radvd was 2.19, which was released 2020-09-23, with opnsense 23.7.11 running that as radvd 2.19_2.

I'm guessing we'll need to wait for an actual 2.20 radvd release before we could see this in opnsense.