Messages

Thanks for confirming! It seems that I had set net.inet6.ip6.use_stableaddr=1 in the tunables from some previous tests, forgot about it, and with the update it started to work. =) Now I can see if I can get that to play nicely with dynamic DNS, but ATM the updates seem to nor propagate at all. Probably I'll have to disable it on the Sensebox because I'm relying on the "dynamic IPv6 host" option already, and that won't auto-update on prefix changes (which it would need to do), but I'll need to wait and see how it actually fares. :)

After finding a window for extended downtime I updated to 26.7.1_. Took several hours but came up just dandy in the end. So far so good. :)
However, now the SLAAC autogenerated address on the WAN IF is not the EUI-64 it used to be. It's still a stable address, but very much different from what the MAC-based version used to be. The latter still is in place on the link-local address of that interface, otherwise I'd have assumed that by some miracle the interface had changed its MAC, but it hasn't. I do have Privacy Extensions active but these generate another address that also changes properly and is listed as temporary just as it should be.

So, was there some change in SLAAC that now generates addresses in a different manner that I missed? I noticed there is the flag "STABLEADDR" in nd6 options=823<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,STABLEADDR>, but IDK whether this was there before or not. So could this be a "stable privacy address" now? This matters for dynamic DNS, naturally.

It probably is connected to your other issue, there seems to be some cruft in your config that creates a race condition for the IP config, and there seems to be a rules issue that may come from the same source. You could check the firewall live view if those ICMP replies are blocked. Also, your route configuration may be borked and have entries that blackhole these ICMP responses.

Like that a disabled but configured route blocks automatic generation of any route with an identical target network. IOW, if you configure a disabled static route to blackhole 192.168.0.0/16 and have this range on your LAN, then the LAN will get no route at all. This simple case is obviously not what you have, but there may be similar routing configurations left over, depending on the complexity of your set-up.

You could attempt a config export, followed by a config clear and a config import. Unless the remains are stored in the config file they should be gone after this withot affecting the intended configuration.

[not]

Yes, but there is so much space wasted and widening it even further creates the problem that all other widgets won't properly fit anywhere anymore unless I put the ddns widget at the top. And if I go to a smaller screen it'd break the layout even more.

There are some other possible improvements to the general GUI layout that I take this opportunity to propose:
1) Move the tab header into the top row, along with the "edit GUI" button. That will remove the entire tab height which is more or less just blank space.
2) Move the footer into the left column, since that seldom contains more than fits on a screen, and frees up the entire footer height in the main view.
3) Make the title of the "Firewall States" widget editable, or change it to something that fits in one column, like "States". This is not terribly important though.
4) Change the FW rule display into a horizontal bar graph like the thermal/sensors widget. That way the text can be inside the graph and not overlap. It'd need to have some form of color inversion / XOR to remain readable though, look at Zone 0 for how it should not end up being like. :)

I guess my comment was directed at the OP. Your (@drosophila) use case seems quite different.

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. :)

Thanks for the clarifications! Initially I got my hopes up that I might be able to use this to get rid of the autogenerated LLA and also get an interface that exclusively receives Privacy Extension addresses. However, at least the latter will probably not work since PE depends on SLAAC and that will automatically give me ULA/GUA addresses on the respective interface that I'd then have to manually separate regardless. Thus I'd still need a script and then it wouldn't change the general situation. :)

Regarding promiscuous mode it would be odd to have attacks through this, since the upstream node will certainly use a switch, so an attacker would have to know your MAC, and even if they do, the likelihood of someone using promiscuous mode without having set up a tight firewall is too low to bother for any common criminal. High-profile criminals like NSA or similar insecurity agencies would be the only ones with sufficient budget and determination if you ended up on their hit-list for criticizing their respective "beloved leader" or say something they don't like.

At least the text is readable entirely, contrary to the ddns widget, which should use the full line for the IP instead of only the first column, and also should line-break the IP if it doesn't fit, like it does with the update time (compare how the "fe" (and all following hextets) is cut off while the "AM" is moved into the next line). The description "Current IP" could be put into the same line if it would line-break, to possibly save one line.
It seems to not have been used with IPv6 much yet. :)

A fix for this is probably non-trivial, because you would have to delete and re-create the virtual IP when the DHCP finally succeeds and that could break other things.

Yes, it would very likely break the gateway monitor, which is very touchy for some reason. My address-reordering script breaks it, anyway.

- Add a Bridge interface and include WAN as a member

So I could configure the WAN IF as static IP and then have the bridged IF get a SLAAC address, apparently without it getting its own LLA? Does bridge mode create overhead? I've read that it puts its members into promiscuous mode, which I'd rather avoid as it might trigger driver bugs.

You are perfectly right: NAT uses the first IP address it finds, which will usually be the first the interface gets assigned. So if you assign the 192.168.11.10 as "virtual" but the primary assignment fails on first try, then, even if DHCP eventually succeeds, 192.168.11.10 will be first in the list and NAT will use that (check ifconfig output for the order, the GUI overview may lie about it). It can't know whether you want to NAT inter-LAN or towards the internet, after all, and there is no way to tell it.
I've had a similar issue and could fix it only by running a cron job that reorders the addresses every minute (the smallest interval it allows to use). Sucks big time.
In your case, it should be possible to hook into the "newwanip" trigger, since it gets a new WAN IP, which this trigger is all about. You'd still need to have a script for it and manually configure the trigger from the command line. Either way, it'll break on a fresh install because none of this gets stored in the config. :(

I seem to remember that both my NICs also are RE8111E, but I can't physically look at them ATM. Maybe you could do a "pciconf -lvvv" on the console and see what it says and compare it to mine:

re0@pci0:3:0:0:    class=0x020000 rev=0x01 hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x8168
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
re1@pci0:4:0:0:    class=0x020000 rev=0x11 hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x1849 subdevice=0x8168
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet

As you can see from the revision, the re0 is quite ancient (compared to the re1 that also is over a decade old; the manual claims it is a RTL8111GR though, so not RTL8111E). The vendor driver has recently ceased to support the RTL84xx chips, but that version is only in the 26.7 so that shouldn't be your issue (the above output is from 26.1.11_10, with the realtek vendor driver that obviously still supports the 84xx).

The age shows (dmesg excerpt):

[1] pcib3: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0
[1] pci1: <ACPI PCI bus> on pcib3
[1] re0: <Realtek PCIe GbE Family Controller> port 0xe000-0xe0ff mem 0xd0700000-0xd0700fff irq 18 at device 0.0 on pci1
[1] re0: Using Memory Mapping!
[1] re0: Using line-based interrupt
[1] re0: version:1.102.01
[1] re0: Ethernet address: <censored>
[1]
[1] This product is covered by one or more of the following patents:           
[1] US6,570,884, US6,115,776, and US6,327,625.
[1] re0: Ethernet address: <censored>
[1] pcib4: <ACPI PCI-PCI bridge> irq 19 at device 28.3 on pci0
[1] pci2: <ACPI PCI bus> on pcib4
[1] re1: <Realtek PCIe GbE Family Controller> port 0xd000-0xd0ff mem 0xd0604000-0xd0604fff,0xd0600000-0xd0603fff irq 19 at device 0.0 on pci2
[1] re1: Using Memory Mapping!
[1] re1: Using 1 MSI-X message
[1] re1: ASPM disabled
[1] re1: version:1.102.01
[1] re1: Ethernet address: <censored>
[1]
[1] This product is covered by one or more of the following patents:           
[1] US6,570,884, US6,115,776, and US6,327,625.
[1] re1: Ethernet address: <censored>

(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...

I'm using NAT66 so the dynamic prefix is no problem, neither are ULAs. This also is a supported configuration that works without hacks. The issue is that I want to get rid of the autogenerated Link-Locals (fe80) and replace them with manually assigned Link-locals (getting rid of them entirely should work if a ULA is statically assigned, but at least OpenBSD refuses to create NDP entries from anything that is not fe80:0:0:0::; Windows, Linux and FreeBSD don't seem to care).
The hack I'd like to preserve has nothing to do with this, it is for the enforcement of the use of the privacy addresses for NAT66, which relies on the ordering of the address assignemts, so a script runs via cron to reorder them as there is no way to reliably hook into actual change events.
I do not want two addresses, I only want one single address per interface. With IPv6, I cannot have that, so the addresses must at least be clearly coherent, which means that the LLA and ULA (and GUA, if used) must have the same suffix so logs will remain readable. But I cannot even do this, instead IPv6 insists on splattering and leaking the MACs all over the place. I'd even have run LLA-only if only NAT would be able to catch them before the kernel forcibly redirects them to localhost, nervermind the fact that NAT would take care of the scope violation (which it is all about, anyway).
It could have been so easy but instead it has to be overly complex to enforce (not just allow) the idealistic doctrine (feels more like dogma) of universal reachability, that you then have to take pains to restrict in any meaningful way. :(

Sorry for the rant. :)

If your Archer device supports it, you can set a static route for the 192.168.10.1/24 LAN through the 192.168.2.2 Sensebox WAN interface. That way you can avoid double NAT. For IPv6 you could probably do prefix delegation or other fancy things to avoid NAT, there are pretty comprehensive How-Tos around here (which I cannot comment on since I intentionally NAT IPv6).

The old one wasn't consistent, either: it used the "play" and "stop" icons for its status display (instead of being actionable buttons as convention makes one expect). I've always wondered why it doesn't use the same status indicator as the ddns and the gateway widget (a colored dot, but sadly its size is not consistent: the dot in the gateway monitor is much smaller than the one in the ddns widget). So the new version is more logical / expectation-consistent than the old one, which is always a plus.
To me, the smaller height of the individual lines is welcome, and the full-line coloring could possibly be toned down into coloring only the part that contains the controls? (BTW, where did the start / stop go? I can only judge from the provided screenshots ATM though, maybe they've been moved).
Coloring the entire line will, if extended to the entire the GUI, end up coloring most parts of the screen in green, which defeats the purpose of a dark theme at least, and will probably be harder on the eyes all in all, and may end up looking cluttered / toy-like?
The ddns widget could use an overhaul as well though, to display the type and name in one line as it does ATM, but to then display the IP address and update time as full line each, instead of cutting it off at the same boundary as the type. The current way is OK for IPv4, but breaks with IPv6. Maybe this is already fixed in the new release already?
Also, the header isn't displayed for the "image" widget either, so it's not entirely unusual. Maybe the header itself could be shrunk for the all widgets, to remove the unnecessary empty space below the orange line, like it is done with the memory, disk, CPU, ddns and some other widgets?

[Edit:]

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.

Thanks for the info, though I don't see how this ties in with the ifconfig setup. The name suggests that the "virtual" addresses are in some way "lesser" than the "main" address. Maybe I'm wrong on this, I'd need to try it and see what ifconfig will end up looking like. I expect all sorts of breakage with this setup if I enter an LLA as "main" (since this should be available first) and the real ULAs as "virtual". Probably it all depends on how, when and where they end up getting set and this may even change on version upgrades. Maybe it's just a naming thing and all addresses get added in one swoop regardless of what they're called. I'll try once I can afford extended debugging downtime.

Edit: so I did some preliminary testing and my initial concerns seem to have been correct: the additional addresses are "lesser" than the primary address and do not get assigned at the same time / with the same priority. For reachability configurations this does not matter much, but the "primary" address is used for outbound connections and NAT, unless routing says otherwise or the addresses get reordered after the fact. For a static setup this is no problem, as I can simply assign my intended LLA as "primary" address and the true ULA as "alias". The system notices this and doesn't autogenerate another LLA even if auto-LLA is enabled. This, however, means that the global IP must be fully static, as the aliases support no dynamic assignments AFAICS, so either one must use GUA with a permanent prefix, or ULAs. This is OK on LAN, but is a real showstopper on WAN: an LLA assigned to WAN as alias is not assigned in time to allow SLAAC to use it, so I cannot disable auto LLA generation - which is the entire point of the exercise. Instead I end up with either an auto-LLA in addition to my own, or no dynamic IP address at all, as SLAAC won't have an LLA to work with when it is asked to negotiate. I'd therefore need a way to run SLAAC after the "alias" address is assigned instead of before - or have the aliases allow SLAAC so the primary address can be static. Of course, I can set up a script that removes the autogenerated LLA once the aliased one is assigned, but this would be yet another modification to keep in mind, track and reestablish on a fresh install.

It would be cool if the config backup would allow me to specify a list of additional files to include in the backup, so I could place such evil hacks there. :)

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...