Project

General

Profile

Bug #8910

DHCP default gateway undefined

Added by Steve Wheeler 7 months ago. Updated 7 months ago.

Status:
Resolved
Priority:
High
Category:
Gateways
Target version:
Start date:
09/18/2018
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.4.4
Affected Architecture:
All

Description

If you have a DHCP dynamic gateway set as the default in 2.4.3 you may or may not have an entry for it in the <gateways> section of the config. It seems more common not to have that.
Without an entry there is no <defaultgw> tag (it is assumed?). When you upgrade to 2.4.4 the default IPv4 and IPv6 gateways, or gateway groups, are explicitly defined but without a default gateway set in the config it results in the default gateway set to 'Automatic' with no tags in the config.
If you only have the DHCP gateway on the system that will work but if you have multiple gateways any of them (it's unclear how that is decided) could become default potentially breaking upstream connectivity.

I hit this repeatably but was able to get past it by manually adding an entry for DHCP WAN:

        <gateway_item>
            <interface>wan</interface>
            <gateway>dynamic</gateway>
            <name>WAN_DHCP</name>
            <weight>1</weight>
            <ipprotocol>inet</ipprotocol>
            <descr><![CDATA[Interface WAN_DHCP Gateway]]></descr>
            <defaultgw></defaultgw>
        </gateway_item>

Associated revisions

Revision 51c3546d (diff)
Added by Renato Botelho 7 months ago

Fix #8910: Restore older versions behaviour and consider 'wan' interface as primary default gateway

Revision c38de34b (diff)
Added by Renato Botelho 7 months ago

Fix #8910: Restore older versions behaviour and consider 'wan' interface as primary default gateway

History

#1 Updated by Jim Pingle 7 months ago

  • Target version set to 2.4.4

#2 Updated by Renato Botelho 7 months ago

  • Status changed from New to In Progress

#3 Updated by Renato Botelho 7 months ago

  • Assignee set to Renato Botelho

#4 Updated by Renato Botelho 7 months ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100

#5 Updated by Jim Pingle 7 months ago

  • Status changed from Feedback to Resolved

This looks good on current snaps. The case I had that broke repeatedly before now comes up with the expected WAN gateway as default each time when everything is left on automatic.

#6 Updated by Pi Ba 7 months ago

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

#7 Updated by Jim Pingle 7 months ago

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.

#8 Updated by Pi Ba 7 months ago

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.

#9 Updated by Jim Pingle 7 months ago

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.

#10 Updated by Pi Ba 7 months ago

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.

#11 Updated by Jim Pingle 7 months ago

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.

#12 Updated by Pi Ba 7 months ago

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)

#13 Updated by Jim Pingle 7 months ago

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.

#14 Updated by Pi Ba 7 months ago

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)

#15 Updated by Jim Pingle 7 months ago

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.

#16 Updated by Pi Ba 7 months ago

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.

#17 Updated by Jim Pingle 7 months ago

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

#18 Updated by Pi Ba 7 months ago

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?)

#19 Updated by Jim Pingle 7 months ago

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.

Also available in: Atom PDF