Messages

Per the release notes there was no change to the nut package.  So what are you all even talking about? :P

Sorry guys, it's not a safe bet that there will always be an EUI-64 address present.  I agree there will be a stable address, but it can be what's known as a 'stable privacy' address not related to the MAC and thus not able to be guessed by Dnsmasq.

For example:

Code Select Expand

3: enp10s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 24:xx:xx:xx:77:cd brd ff:ff:ff:ff:ff:ff
    inet 172.21.30.100/24 brd 172.21.30.255 scope global dynamic noprefixroute enp10s0
       valid_lft 77087sec preferred_lft 77087sec
    inet6 fd5a:xxxx:xxxx:1003:5dec:dd53:a78e:2964/64 scope global temporary dynamic
       valid_lft 86375sec preferred_lft 76947sec
    inet6 fd5a:xxxx:xxxx:1003:xxxx:610f:948:xxxx/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86375sec preferred_lft 86375sec
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

The management address here ("mngtmpaddr") does not have the signature "ff:fe" bits in the host part and the 'tmp' in the name gives it away.  The host is using this:

You cannot view this attachment.

"EUI64" is the other option on the drop-down menu, but they are mutually exclusive.

[ra-names]

Dnsmasq cannot register the IPv6 address of clients using privacy extensions, so maybe that is a win for Kea+DDNS?

Not just the Privacy Extension one or any IPv6 Address ?!

Sorry, couple days late responding...

I misunderstood about Kea (clarified by @Monviech).

As for Dnsmasq, my understanding is that SLAAC addresses are only registered if the host has both an IPv4 reservation and is using EUI-64.  When you have privacy extensions enabled, it doesn't know what to register and so you get an A record only in DNS.

I could be wrong about this but that's what I observe on my desktop and also how I interpret this part of the manual (under --dhcp-range):

ra-names enables a mode which gives DNS names to dual-stack hosts which do SLAAC for IPv6. Dnsmasq uses the host's IPv4 lease to derive the name, network segment and MAC address and assumes that the host will also have an IPv6 address calculated using the SLAAC algorithm, on the same network segment. The address is pinged, and if a reply is received, an AAAA record is added to the DNS for this IPv6 address. Note that this is only happens for directly-connected networks, (not one doing DHCP via a relay) and it will not work if a host is using privacy extensions. ra-names can be combined with ra-stateless and slaac.

Dnsmasq cannot register the IPv6 address of clients using privacy extensions, so maybe that is a win for Kea+DDNS?

BTW, my desktops usually have both a stable and a rotating privacy address.  I think most Linux desktops now enable them by default when a desktop environment is initially selected during installation.  I think the stable address on desktops is usually not EUI-64 but on server installs it is (and those would obviously also not be using privacy extensions).  At least this is my experience with some Debian-based ones.

Thanks for the quick fix @franco.

Anyone looking into NPTv6 can also refer to https://forum.opnsense.org/index.php?topic=51781.0, especially the first couple of posts from @Maurice on how to do it properly.

Very cool that NPTv6 can automatically map prefixes like that.  I had assumed it needed a manual mapping for each /64.

So now I have just the one rule active for the /61 internal prefix and tracking interface with ID 0x8:

You cannot view this attachment.

It's working well.  x:1000 maps to GUA ID 0x8, x:1003 to ID 0xb, etc. :)

Inter-VLAN IPv6 works as expected and hosts are talking over their ULA addresses, except, again, that UDP traffic to/from the UOS controller (only when the webUI is active).  For some reason this is using the GUA prefix and it might be a UniFi quirk.

The good thing is that the traffic seems to be terminating at the router.  I've disabled the "out" block rule on the loopback device and this is what I see when I trace/ping the UniFi controller IP on the GUA prefix:

Code Select Expand

$ tracepath 2601:xx:xxxx:3168:xxxx:xxxx:xxxx:f30a
 1?: [LOCALHOST]                        0.011ms pmtu 1500
 1:  fd5a:xxxx:xxxx:1003::1                                0.191ms
 1:  fd5a:xxxx:xxxx:1003::1                                0.162ms
 2:  fd5a:xxxx:xxxx:1003::1                                0.186ms asymm  1
 3:  fd5a:xxxx:xxxx:1003::1                                0.162ms asymm  1
...
30:  fd5a:xxxx:xxxx:1003::1                                0.189ms asymm  1
     Too many hops: pmtu 1500
     Resume: pmtu 1500


Code Select Expand

$ ping -6 -c 3 2601:xx:xxxx:3168:xxxx:xxxx:xxxx:f30a
PING 2601:xx:xxxx:3168:xxxx:xxxx:xxxx:f30a (2601:xx:xxxx:3168:xxxx:xxxx:xxxx:f30a) 56 data bytes
From fd5a:xxxx:xxxx:1003::1 icmp_seq=1 Time exceeded: Hop limit
From fd5a:xxxx:xxxx:1003::1 icmp_seq=2 Time exceeded: Hop limit
From fd5a:xxxx:xxxx:1003::1 icmp_seq=3 Time exceeded: Hop limit

--- 2601:xx:xxxx:3168:xxxx:xxxx:xxxx:f30a ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2076ms

No other observed issues ATM.

¯\_(ツ)_/¯

Thanks for the tip!  I'll update the OP with a note to follow your posts.

Hi @Maurice,

I want to implement your approach but I only get a /60 from my ISP.  Is there a clean way I could use a larger internal NTPv6 prefix than the /64 I currently have?  I'm not certain but it might help with an issue I just noticed.

I have a UniFi OS controller on LAN at the fd5a:...:1000:...:f30 address.
I have a web client (trusted PC) on CLEAR at the fd5a:...:1003:...6ac2 address.

When I access the UniFi controller those two pass lots of UDP packets but at some point the UniFi host picks up the external prefix (2601:...:316f/64) and starts trying to send traffic to my web client on the translated GUA prefix.

You cannot view this attachment.

This is the only case I've seen so far where this happens.  I put an "out" block rule on the tracking interface (lo1) to try and prevent leaks to WAN though I'm not certain that's effective. This would be difficult to filter on the LAN interface itself.

Maybe has to do with the /64 -> /64 translation?

was hoping for someone with more knowledge...

Hey no problem. :)  Take care.

Lots of firewall states?  Do you see a big increase in Reporting->Health->System (states) for that time period?

[Some thoughts:]

Some thoughts:

For me this is an experiment to see if it helps with some specific issues (and to learn something new) but I don't plan to keep this configuration long term.  The main problem is that if IPv4 is enabled then many web clients and browsers will prefer that over a ULA for egress, so IPv6 will almost never be used except as a fallback.  I think there are ways to configure that on a per-client basis but I'm not going to try.

(UPDATE: On a subnet with Android mobile clients I see much higher IPv6 usage, so those may already be de-prioritizing IPv4.)

I think this method becomes more attractive in an IPv6 only network where the ULA route is the only one, because then you can have true independence from the ISP's delegation for internal networks and there is nothing competing with the ULA for priority.  Still, it flies against the IPv6 design principle where everything is globally addressable and any kind of NAT (even just prefix translation) should not be needed.  As already pointed out, addressability != reachability.

There are however a few annoyances that this attempts to work around and they mainly have to do with challenges associated with dynamic prefixes.  Put bluntly, many ISPs are not following RIPE recommendations^[1] for persistent /48 prefix assignments.  Most of the below reasons stem from that fateful decision.

I think the most obvious reason is if you don't have enough /64 prefixes for your subnetting.  If your ISP only delegates a /60 and you need more than 16 subnets (or 15+WAN, because in DHCPv6-PD the WAN interface consumes one) then you might consider using ULAs for additional subnets and translating them to one of the existing prefixes.

A second reason is because of firewalling challenges^[2] related to dynamic GUAs.  In some cases it's difficult to enforce boundaries using only the network aliases that OPNsense maintains.  For example, you might be tempted to create an alias named "IPV6_INTERNET" and define it as 2000::/3, then use that in filters or policy routing.  The problem is that your GUAs are included in that and (at least as of 26.1) you have no way to exclude your dynamic prefixes.

A third reason is because some particular quirks may affect you.  My ISP gives me a long-lived prefix which persists even after modem reboots.  The ISP also reboots the modem weekly for updates and network maintenance.  This causes the prefix to become deprecated and clients should not use the same prefix again, by some unfortunate language^[3] in section 3.5 of RFC 8981.  The effect is that until/unless clients reset their network interfaces, SLAAC fails to generate new addresses which is particularly insidious if you rely on temporary addresses with IPv6 privacy extensions.  If there's one thing I cannot abide, it's silent failure^[4] of privacy related functions and in my recent testing NPTv6 does fix this.

All said however, I think NPTv6 for these use cases is still not the second, third, or even fourth best alternative.  Before this is considered at all I would look at something like ndp-proxy-go^[5] or the trick of borrowing an unused prefix from somewhere^[6], if you can.  Just beware that some ISPs (like mine) do Stupid Things^TM with RAs (like advertising ULA routes) so the ndp-proxy is not recommended then.

I'll mention also this article^[7] linked by @Javier® in case you are interested in a true NAT option, although the described solution is centric to the OpenBSD flavor of pf and would need some adaptation for OPNsense.  This one still has the same problem of ULA priority as NPTv6, though.

NAT impressions:

Regarding outbound NAT, in my testing I see that NPTv6 does not seem to interfere with it.  I have a VPN interface with an attached gateway and traffic leaving that interface is NATed to the wireguard tunnel address.  I think because the Outbound NAT / SNAT rules have higher precedence than the NTPv6 / binat rules in the pf ruleset those are overriding the NPTv6 rules:

You cannot view this attachment.

Code Select Expand

root@firewall:~ # cat /tmp/rules.debug | grep nat
...
nat log on wg1 inet from any to any -> (wg1:0) port 1024:65535 # SNAT on WAN_VPN0
nat log on wg1 inet6 from any to any -> (wg1:0) port 1024:65535 # SNAT on WAN_VPN0 (IPv6)
...
binat log on igc1 inet6 from fd5a:xxxx:xxxx:1002::/64 -> (lo1:0)/64 # NPTv6 WAN<->VPN (/64)

So interactions with outbound NAT seem safe.

Finally, what about ingress?  Well, for hosts behind the firewall I would guess that NAT port forwards / DNAT should still work.  I don't presently host anything and haven't tested it.


[1]: https://www.ripe.net/publications/docs/ripe-690/
[2]: https://github.com/opnsense/core/issues/7000
[3]: https://www.rfc-editor.org/rfc/rfc8981.pdf
[4]: https://forum.opnsense.org/index.php?topic=44435.0
[5]: https://forum.opnsense.org/index.php?topic=44071.0
[6]: https://forum.opnsense.org/index.php?topic=31374.msg151647#msg151647
[7]: https://eradman.com/posts/ipv6-strategy.html

[**UPDATE**]

Just some notes on the configuration because I didn't find a tutorial here.  Let me know if it exists and I'll link to it.

I'll give some thoughts about this in post #2.

If you're looking to set up IPv6 the right way, this is not it.  Please go here instead.

---

**UPDATE**: It's not necessary to map each /64 as I did here and it may cause problems.  See the first few posts from @Maurice below (posts #2-4).

(Tested on OPNsense 26.1.7_1-amd64)

The objective is to use static ULA /64 prefixes on internal interfaces (e.g. LAN) which are controlled by you and independent of the ISP, but which get translated on egress to a delegated prefix.  The first 64 bits of the ULA get overwritten but the lower 64 (host) bits remain intact.  This means if you use privacy extensions on a web client those temporary address host bits will be preserved.

This is how it might look in firewall logs:

You cannot view this attachment.

You need at least one internal interface tracking the delegated prefix from WAN.  This is a required input to the NPTv6 rule so that it knows which external prefix to translate to.  I think it's required that your ISP delegates at least a /60 so that one of the prefix IDs can be used for the tracking interface, but don't quote me on this.  I don't know how you would track a /64 delegation and you unfortunately cannot have the NPTv6 rule just use whatever is assigned on WAN already (see Note 3 below).

You can reuse the same tracking interface in multiple NPTv6 rules, however.

You can also use a dedicated loopback as the tracking interface in case you don't already have one.  In my testing the new 'Identity Association' (idassoc) mode works for this purpose though I guess you can also use 'Track Interface (legacy)' (track6).  I haven't tried it.  Take care to disable any automatic radvd configs that get created in that case.

1. Go to Interfaces->Devices->Loopback and add new device.
2. Go to Interfaces->Assignments and assign this device with a name.
3. Go to Interfaces->[name] and enable it.
- Leave the IPv4 config set to None.
- Change the IPv6 config to "Identity Association" and choose your WAN as the parent interface.
- Choose an available prefix ID and save.

Note 1: don't add any rules on this interface as it won't be passing traffic.  It's just there to hold the prefix.

You cannot view this attachment.

Finally the NPTv6 rule itself:

1. Go to Firewall->NAT->NPTv6 and click the "+" button to add a new rule.
- Set "Interface" to WAN (this is the interface that the rule applies to for outbound translation)
- Set "Internal IPv6 prefix" to one of your ULA prefixes for an internal network.
- Leave "External IPv6 prefix" blank.
- Set "Track Interface" to the internal interface tracking the prefix, or the loopback we set up earlier.
- Save.

Repeat for additional ULA prefixes you need to translate.

Note 2: you don't need to specify the internal interface anywhere.  NPTv6 cares only about prefixes.

Note 3: if you don't specify either a tracking interface or an external prefix for translation (which we don't use for dynamic prefixes), there is currently a validation bug that will not stop you from doing this and it will cause IPv6 services that you have listening on WAN (e.g. WireGuard tunnels) to break.

And that should be it. This is how it might look for several subnets getting translated to the same tracking interface's prefix:

You cannot view this attachment.

I don't think setting a static IP would cause a problem.  It's been a while since I did a fresh install but I think Dnsmasq is the default DHCP server now and as long as you took all the defaults during the installation and didn't change anything it should be set up already with a DHCP range for the 192.168.1.0/24 subnet.

During the installation the system might have asked you if you want to make manual interface changes or IP assignments.  I'm assuming you didn't.  In that case you should probably be seeing a screen like this:

https://docs.opnsense.org/manual/install.html#initial-configuration

Unfortunately you can't copy/paste because you're using VGA, but if you could take a picture or let us know what you see on the bootup screens maybe something will stand out.

The 'igc' driver for the i226V ports is very well supported in FreeBSD/OPNsense out of the box so at a bare minimum your LAN interface should be working, barring any problems with your hardware of course.

EDIT: You can replay the kernel messages with the "dmesg" command from the shell (menu option 8 when you log in as root).  Use "dmesg | more" to page your way through with the space bar.

By default on a fresh OPNsense installation you'll get the first port (igc0 in your case) configured as the LAN interface with 192.168.1.1 (subnet 192.168.1.0/24).  Your second port (igc1) would be the WAN port, which it sounds like it's not able to get an internet connection yet.  That's not needed if you're just trying to access OPNsense, anyway.

The DHCP server should already be running on OPNsense so you don't need any static config on your laptop.

Make sure you are connecting to the igc0 port and not any of the others.  Hopefully your router has the first port marked in some way.  They aren't always obvious or in left-to-right order.

I have a small display connected by HDMI that lets me see the the text-mode setup menu.  A keyboard allows me to change settings, reboot, etc.  But I have no way to open a serial console as the instructions suggest.

Since you already have a VGA console then the serial console should not be needed.

OBTW, in case it matters, I did pay for a one year license.

Doesn't matter here- this is a community support forum :)  Though thank you for supporting them.  We all benefit.

Since you paid for the business edition license, don't forget to switch your configuration to it once you have access to the OPNsense UI.  The one you have installed now (26.1) is a Community edition.  The latest Business edition is 26.4:

https://docs.opnsense.org/releases.html

You can activate your Business edition under System->Firmware->Settings

The official hardware sizing guide of OPNsense states that to handle a throughput of over 750Mbps the "recommended spec" is needed.
And the recommended spec indicates 8GB of RAM.

But is that enough for 25Gbps or will it handle just a little over 750Mbps?

Maybe the guide assumes that above a certain throughput you are probably pushing lots of states or have some number of users/services/aliases/IDP etc.?  It may or may not be the case depending on your particular network.

I might learn something new here but I'm tempted to say that as long as you have enough RAM for your needs (and some buffer) then the throughput shouldn't be a function of the amount of RAM.  It's probably more affected by the RAM spec, CPU, PCIe lane configuration, etc.  Just my assumption.

I ran test-ipv6.com on Windows and it gave a 10/10 result, although the response times were slightly slower than usual. On Linux, the same test consistently gave a 0/10 result, failing to detect the IPv6 address.

Is pppoe maybe a factor here?

FWIW, I'm on a Linux desktop (ISP uses DHCPv6) and not seeing this.