pfSense

Sadly now i cant move my fiber gateway above the old adsl wan interface anymore.. I know i want it, but the gui wont save it/load it properly anymore. perhaps this could be a compromise of the two?: https://github.com/pfsense/pfsense/pull/3988

Why would that matter now? What loss of functionality is there? You can select it specifically, or setup a gateway group with it on Tier 1.

Not selecting WAN by default was breaking a number of people in unexpected ways based on whether or not another interface with a gateway came before WAN alphabetically.

Forgot to 'watch' this issue, so replying a little late (thanks for the github question/copy i did get notified by).

The 'automatic' gateway selection selects a gateway from the list 'top-down' determined by its 'up' status. For this to work it is required to have the most preferred gateway listed as the first one. And while that could commonly be 'wan' there is always the chance that a second,newer,later added gateway would be preferred over the old 'wan' and without re-assigning interfaces it could be nice to have OPT1 as the default-route while using wan when opt1 is down, this all while not needing to create a gateway group.. A gateway-group could indeed also allow for pretty much the same kind of functionality with a bit more configuring.. Even if you do use gateway-groups, it can be nice to manually arrange the order of gateways..

With current code items can be 'ordered' but the top one is fixed by the system.. imho 'wan' is just another interface without any special meaning.. even if the system-default would pick wan when nothing is specified, to make things easy for the home-user, it should be changeable by the advanced-user.

I think with the added pull-request, both would be accommodated.

But moving something to the top by ordering it alphabetically is a kludge. I don't think we should go out of our way to support that. If someone wants to control the behavior, the have the means to do so by selecting the default manually and/or using a gateway group for default that behaves exactly the way they want.

The default automatic behavior is just that -- default. The way it works right now is the best for the vast majority of users. Changing that so it happens to trigger alphabetically could be confusing to anyone that doesn't understand the behavior or why it might change. Just by editing and saving a gateway the behavior could change unexpectedly out from under someone unintentionally. That is not ideal at all.

I'm not intending things to be 'alphabetically', i want them to be in the order of importance. As for saving things, it should not overrule the user chosen position because the system thinks it knows better.

There shouldn't be an "order of importance" on the list of gateways though. That's what the default gateway group is for. I see they can be manually reordered, but I'm not sure they should be. It isn't obvious to the user that the order is important aside from cosmetics.

I'm sure you remember the old 'gateway switching' option? It used the gateways in order they were listed as well.. (without being able to influence that order though.) So for people that used that option the 'automatic' mode would be the closest match. As for making it more obvious, i guess it could indeed use a little remark that says automatic will use them in order. And anyhow how else would 'automatic' pick a gateway, take the one with the lowest latency?? (if 'wan' is down)

But that's what the gateway group is for. I don't see any good reason to have two mechanisms to do the same thing. The way it is now preserves the old behavior. If they want to override that, use a group and do it the right way. If we do anything here it should be to remove the reordering entirely.

I think the 'automatic' mode was probably something we wanted because the old behavior of assuming wan=default wasn't working, and it wasn't complete enough because people continued to have problems afterward (like this ticket). Automatic should just be like the old gateway switching option going down the list of gateways like they were in the past. As above, if they want to control that, use a group.

Having both methods is only going to confuse people.

Jim Pingle wrote:

Automatic should just be like the old gateway switching option going down the list of gateways like they were in the past.

Just going down the list without any control over the order of that list is bad as well.. imo.

As for breaking existing setups upon upgrade, yes i guess some (fairly common) scenario was missed during my tests. (and no-one seems to have reported it during beta's for me to look deeper into how to handle the scenario better)

Pi Ba wrote:

Jim Pingle wrote:

Automatic should just be like the old gateway switching option going down the list of gateways like they were in the past.

Just going down the list without any control over the order of that list is bad as well.. imo.

The control is adding and using a gateway group. Anything else is a POLA violation. We do not want to surprise users by changing the behavior they were used to before. That's how we ended up with this and some other similar tickets.

Control over 'gateway switching' ~= 'automatic' is done by the order of the list. Not having control over that order makes both options pretty much useless.

And yes that behavior changed so significantly that people ended up without a working internet connection is bad indeed, i do like POLA... I wish i could have known the cause and fixed it before release, i am sorry for that.. but i guess that is to late now.

Pi Ba wrote:

Control over 'gateway switching' ~= 'automatic' is done by the order of the list. Not having control over that order makes both options pretty much useless.

I guess I don't see that. There are a few possible options:

1. Static default where the user chose their default gateway specifically.
2. Automatic -- Similar to the old Default Gateway Switching where the order is guessed by the system. Not ideal, but identical to the old behavior. No real control here, but that's to be expected since there was no control before.
3. Default Gateway Group -- User configures a gateway group with the specific gateways they want using tiers to place them in the exact order they want, giving them full control over the entire process.

If the user wants control, they use option 3. If they don't know/care and just want it to switch automatically like before, they use option 2. If they don't want any switching, they use option 1. Upgraded users should land on 1 or 2 to match what they had before and behave identically as they expect. They can opt to change to 3 easily by adding a new gateway group and selecting that as default.

That all seems logical and intuitive for the user to figure out (perhaps assisted by documentation in the near future).

Behavior of 1 and 3 are clearly defined (i think), no argument there.

But 2 'automatic' still needs some information to define what is 'preferred'. And well that preference is defined by the order..
If a 'wan' gateway is dynamically added, its okay to have that as default first option. (which is what Renato's commit does)
but then what would happen if that go's down.. it would take the 'second' gateway right.? which is determined by their order.. imho the user should be able to swap second and third gateway if he wanted, and also primary / secondary..
If wan-gateway is statically configured it could be disabled, or it should be able to be set to lower priority than other gateways, which is what the anchor's (should) allow to do. (they would after my added PR)

Yes option 3 allows the same and more(usage in rules), but well its just 'less simple' overall..

I guess we need to a final decision :) i think all arguments have passed the table. (maybe Renato can share his opinion?)

The moment you give a user any control over 2, it starts trying to replace 3. 2 should just be completely hand-off automatic as the name implies and how it behaved before.

If the user cares how the next gateway is picked when one goes down, they need to setup a group.