[bug]: OOBE firewall calculation needs more options on subnets

[chrsmj]

FreePBX Version

FreePBX 17

Issue Description

Filing as a bug because the calculation assumes a /24 even if you are on a /8. This could be probably demo'd on something like Proxmox, with Virtual Machines at the following IPs and /8 subnets:

New PBX: 10.4.4.4/8

Client PC to access the PBX GUI: 10.5.5.5/8

...in such a situation, the OOBE running on 10.4.4.4 will ask you to allow 10.5.5.5/24 and not 10.5.5.5/8

Reported on the forums at https://community.freepbx.org/t/inaccessible-new-installation-after-initial-configuration/105666

Similar but not the same as issues #88, #247 or #639.

Operating Environment

v17

Relevant log output

[blazestudios97]

This shouldn't be used anymore during the wizard as it is flawed and works on outdated assumptions. This entire process is getting the IP from $_SERVER['REMOTE_ADDR'] which is a singular IP and there is nothing to gleam the subnet it is apart of. That's a flaw. The outdated assumptions of the person must be coming from a private network and that network is a /24 (not a class C as documented in the code. Completely different) and that entire subnet should be allowed. That is not the case in this day and age.

I have setup numerous systems in the cloud, this process always wants me to give access to a /24 of public space. Public IPs are generally in smaller subnets than a /24 so giving the full /24 access still allows them access (unlike the OP in the thread referenced who was using a larger subnet and IPs were outside the /24). This just opens the system to a wide range of public IPs that can get into the system now. Flawed.

The wizard should give access to the single IP of the user going through the wizard. After that is completed, the user can be prompted to add subnets properly. That means the /24 (or whatever) of private space is added to the Local chain as it should be and any external subnets can be added to the Trusted or other chains as needed.

So currently not only does this break systems that on are larger than /24 subnets, it also opens up more public IPs than it should as there is no validation of an IPv4 address being RFC1918 or not.

At the very least, if this is going to stay in, make this point of the process ask if the /24 subnet is valid and allow the subnet to be modified if needed.