pfSense

No it's not! I clearly wrote:

That is on the latest pfSense plus version.¶

above which shouldn't leave any room for interpretation, so don't tell me it's fixed when I am literally just experiencing that issue. Anyways, I'm over this. Fix it or leave it broken, I don't care anymore, I will switch to a different firewall solution and if another customer reads this report they should do the same. You turned pfSense from open source software into a product (which is not necessarily a bad thing), so I can and will expect the quality of a commercial product. That includes that bug reports are read fully and that at least basic testing is done so that bugs that render the product useless are found before releases. I have never seen so many regressions in a product, the previous release was complete junk and I needed no less than 10 patches to have it in a partially working state, but this one is even worse, I don't have time to have a multiple hour downtime and go bug hunting everytime I upgrade this product. I'm just glad we bought our appliance through a reseller here in the european union, that thing will go back tomorrow as I am so done with this.

That "fix" for #6880 is causing exactly these issues by the way. You basically "fixed" multiple clients starting, that's great but that doesn't mean it's working, especially if you just delete the config midway while writing to it.....

By the way: I have found and fixed this issue already and I can tell you that basic testing would have found it aswell.

I am actively using it on 22.05. It works, and does not behave as you describe.

: cat /var/etc/dhcp6c.conf 
interface ix3 {
        send ia-na 0;   # request stateful address
        send ia-pd 0;   # request prefix delegation
        request domain-name-servers;
        request domain-name;
        script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc na 0 { };
id-assoc pd 0 {
        prefix-interface igc0 {
                sla-id 0;
                sla-len 4;
        };
        prefix-interface igc1 {
                sla-id 1;
                sla-len 4;
        };
        prefix-interface igc2 {
                sla-id 2;
                sla-len 4;
        };
};

interface ix2 {
        send ia-na 1;   # request stateful address
        send ia-pd 1;   # request prefix delegation
        request domain-name-servers;
        request domain-name;
        script "/var/etc/dhcp6c_opt1_script.sh"; # we'd like some nameservers please
};
id-assoc na 1 { };
id-assoc pd 1 {
        prefix-interface igc3 {
                sla-id 4;
                sla-len 4;
        };
};

Furthermore I have LANs tracked from both WANs:

 LAN1 (lan)      -> igc0       -> v4: 10.17.0.1/24
                                  v6/t6: 2001:db8:1:eed0:208:a2ff:fe12:169e/64
 LAN2 (opt4)     -> igc1       -> v4: 10.17.1.1/24
                                  v6/t6: 2001:db8:1:eed1:208:a2ff:fe12:169f/64
 LAN3 (opt5)     -> igc2       -> v4: 10.17.2.1/24
                                  v6/t6: 2001:db8:1:eed2:208:a2ff:fe12:16a0/64
 LAN4 (opt6)     -> igc3       -> v4: 10.17.3.1/24
                                  v6/t6: 2001:db8:2:ee34:208:a2ff:fe12:16a1/64

So either there is something wrong with your install and isn't isn't running 22.05, or there is something else wrong with your setup/environment -- either way, take it to the forum. It's working for me and others.

I know exactly why it's working for you (and for some others aswell, not for all though), but it's not my job to fix your product if you lack basic regression testing before releases. So I suggest you start setting up some test scenarios and figure out where the bug is, or start staring at the code (which works aswell). Or since I was kind enough to post my config you can also try to figure out what's needed to create that config and then you will reproduce this.

I can tell you that basic unit/regression testing would have found this bug, which is why I am so upset about this. Usually I would provide the solution as I've done it in the past aswell but I rather get the impression that such free work is exactly what you want so you don't put any effort into testing anymore as users will report bugs and provide solutions. That's acceptable for open source software but not for a commercial product. Show me your effort and what you have done (and a single configuration is not sufficient, there are many configuration options, testing just one of them is not enough and you haven't even tested what I mentioned in the bug report....) then I will be glad to help and maybe even reconsider my decision to switch to a different manufacturer, but not like this.

Unit tests are a concept that is easy to suggest but not at all easy to implement. It's something we are working toward but it's a long road.

If you have more information you should provide it instead of giving hints and suggestions and being vague. Even better, a pull request with a suggested fix.

It works for what most users would do in practice, there are always likely to be edge cases not covered by the GUI.

To reiterate: The issue stated in the title and the bulk of the description here is demonstrably false. If there is some other requirement (e.g. override configurations) then that should be the subject and lede, not an afterthought that wasn't even stated as being definitively part of the configuration.

If you want to make a new, and more accurate, bug report with just the facts and without the colorful language, then we might be able to find and fix potential problems.

If you would do proper testing (which means that at least multiple options that the GUI offers are tested, not just this works-for-me-attitude where a single test-case passing basically means it's working) then implementing unit tests would be a major relief. Of course if there's no testing or the test being "runs on a machine in the lab - works!" implementing unit test seems like a huge effort, but compared to proper manual testing it's a huge relief as it saves a lot of time. You don't seem to understand that your testing is not enough, you released 2 versions of a commercial product in a row that contain major issues, that's pretty much game over.

As I said: This appliance will be returned to the reseller which is luckily in the EU so we'll get a full refund for it, I gave more than enough pointers in the right direction (I even posted the config created, as you might have noticed yours looks different) but since I am not getting paid for this (in fact I had to pay for the hardware with the pfSense plus license) I am not going to provide the solution, especially since I get the impression that this is somehow part of your business model. If you want to fix this you can either search the bug yourself, hope that someone else finds it and does the work for you for free or negotiate some kind of contract with me so that I get paid for the work I am doing to fix a product that should be working in the first place. I'm not going to work for free (or even worse: pay for a product so I can fix it and provide those fixes for free) as that's clearly what you want and are expecting. Again: You turned this into a product, so I am expecting the quality of a product. Others might have different views on that and if they want to spend money to buy pfSense plus and then spent time to make it usable they can certainly do that, I rather buy a product from a different manufacturer though.

If you found a fix and want to compare it to my fix:

# sha256sum /etc/inc/interfaces.inc
b2e61aaf097e4ee4e343cb6c48c1db05cb1a61ed4df5feb34f7ed9a1b872b266  /etc/inc/interfaces.inc

# sha256sum /etc/inc/interfaces.inc
6490a3b262045a16cb291bf47566c1ae15fc3cbce691e48f9c37707eb4ec62fd  /etc/inc/interfaces.inc
<pre>

We do test a variety of configurations but testing every possible iteration is not possible. Even with unit testing there is a limit to how many combinations can be tested.

We have to rely on cooperation from customers and the community to give us meaningful feedback so we can address bugs. If we get incomplete or vague information there is only so much we can do.