Bug #12436
open
Pppoe server config gui does not allow setting of chap authentication, and sets the network start address for allocation to 0
Added by And Ritchie about 3 years ago.
Updated about 3 years ago.
Description
It is not possible to enable chap authentication via the gui. The service config file is generated with pap authentication only.
Also the client address allocation keeps being defaulted to 0 I.e if I want the address allocated to the first client to be 192.168.1.1 the gui will reset it to 192.168.1.0 upon save.
- Affected Version set to 2.5.2
And Ritchie wrote:
It is not possible to enable chap authentication via the gui. The service config file is generated with pap authentication only.
Feature request #12438 created.
Also the client address allocation keeps being defaulted to 0 I.e if I want the address allocated to the first client to be 192.168.1.1 the gui will reset it to 192.168.1.0 upon save.
Changing this behavior can confuse users with existing installations.
Hi Victor,
This behaviour causes assigned client ip address to be 0 thus invalid.
E.g. 192.168.1.0 is not a valid client address. Which is what gets allocated to the connected client when it connects.
- Status changed from New to Not a Bug
An IP address ending in .0 is only invalid when used as a part of an actual subnet. In point-to-point interfaces like PPPoE it is used differently (x.x.x.x -> y.y.y.y, /32 mask on both) so it is valid there. Similarly, it's also valid if used purely for NAT and not assigned as a subnet to an interface.
It's better for various automated parts of the configuration to have the client address range expressed as a subnet (e.g. for firewall rules/etc) but the clients are not actually all in the same "subnet" from a network interface perspective, they are each on their own interface using a single isolated address.
Since the other feature request was moved to its own separate issue I don't see anything actionable here.
- Status changed from Not a Bug to New
Jim Pingle wrote in #note-3:
An IP address ending in .0 is only invalid when used as a part of an actual subnet. In point-to-point interfaces like PPPoE it is used differently (x.x.x.x -> y.y.y.y, /32 mask on both) so it is valid there. Similarly, it's also valid if used purely for NAT and not assigned as a subnet to an interface.
This is valid, but this is still incorrect behavior
fix: https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/435
it doesn't break the existing installations as it doesn't modify remoteip which is stored in config.xml
Viktor Gurov wrote in #note-4:
Jim Pingle wrote in #note-3:
An IP address ending in .0 is only invalid when used as a part of an actual subnet. In point-to-point interfaces like PPPoE it is used differently (x.x.x.x -> y.y.y.y, /32 mask on both) so it is valid there. Similarly, it's also valid if used purely for NAT and not assigned as a subnet to an interface.
This is valid, but this is still incorrect behavior
Why would it be incorrect? It is not technically a subnet. It is a range/pool of addresses. If you skip the first and last IP address in the configured range by treating in incorrectly as a subnet, it will have less available addresses to use for clients. For example if you set the mask to /30 right now you could fit four clients in that range, not two (or three if you only skip the first one).
If anything, language referring to it as a subnet should be corrected. It uses subnet-style configuration for historical reasons (mostly because it's easier to deal with in automatic firewall and NAT rules) but could just as easily use a hand-entered starting and ending address if the backend code was changed appropriately.
Also available in: Atom
PDF
Updated by Viktor Gurov 
Updated by 
Updated by