Project

General

Profile

Actions

Todo #3196

closed

Improve IPv4 address validation on interface setup (GUI and console) and setup wizard

Added by Jim Pingle over 10 years ago. Updated about 10 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Interfaces
Target version:
Start date:
09/12/2013
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:

Description

If you enter a LAN IP into the Setup Wizard such as x.x.x.0/24 or x.x.x.255/24, the setup wizard does not complain and will continue with the (invalid) IP setup. The setup wizard should reject the input if the user enters the subnet ID or broadcast IP of a subnet.

Currently it does reject if it's obviously wrong, e.g. x.x.x.300, via JavaScript, but it misses the above case.

The only potential exception would be if the CIDR were 31 or 32, if we choose to support those in the wizard, in which case it may be a valid configuration.

Actions #1

Updated by Jim Pingle over 10 years ago

  • Description updated (diff)
Actions #2

Updated by Phillip Davis over 10 years ago

I have done this to myself when braindead! It also allows x.x.x.255/24 - it should prohibit the 1st and last address of a subnet, unless a 31 or 32 mask is given. Needs to make sure to handle all unusual subnets - e.g. 192.168.2.16/28 and 192.168.2.31/28 are the beginning and end of a /28.

Actions #3

Updated by Renato Botelho over 10 years ago

  • Subject changed from Improve IP address validation in the Setup Wizard to Improve IPv4 address validation on interface setup (GUI and console) and setup wizard
  • Target version changed from 2.2 to 2.1.1

It's not only setup wizard, but you can also use network or broadcast addresses on interfaces.php and console.

Actions #4

Updated by Renato Botelho over 10 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #6

Updated by Phillip Davis over 10 years ago

I did GitSync and tried this on the console. Here is some sample output:
@Enter an option: 2

Available interfaces:

1 - WAN (vr2 - dhcp, dhcp6)
2 - LAN (vr0 - static)

Enter the number of the interface you wish to configure: 2

Enter the new LAN IPv4 address. Press <ENTER> for none:

192.168.48.0

Subnet masks are entered as bit counts (as in CIDR notation) in pfSense.
e.g. 255.255.255.0 = 24
255.255.0.0 = 16
255.0.0.0 = 8

Enter the new LAN IPv4 subnet bit count:

24

You cannot set network address to an interface
Enter the new LAN IPv4 subnet bit count:

20

You cannot set network address to an interface
Enter the new LAN IPv4 subnet bit count:

19

Enter the new LAN IPv4 gateway address. Press <ENTER> for none:

Enter the new LAN IPv6 address. Press <ENTER> for none:

Do you want to enable the DHCP server on LAN? [y|n] y
Enter the start address of the IPv4 client address range: 10.30.20.0
Enter the end address of the IPv4 client address range: 10.30.20.99
Disabling DHCPD...Done!

Do you want to revert to HTTP as the webConfigurator protocol? (y/n) n

Please wait while the changes are saved to LAN... Reloading filter...
DHCPD...

The IPv4 LAN address has been set to 192.168.48.0/19
You can now access the webConfigurator by opening the following URL in your web browser:
https://192.168.48.0/

Press <ENTER> to continue.
@
After putting in the bad data (192.168.48.0/24) it gives the error message, but just prompts again for the subnet bit count. There is no easy or obvious way to get back to the IPv4 address prompt to correct the real problem. I faked it by purring a bigger subnet bit count until 192.168.48.0 was no longer the bottom end network address. Of course the user can also press ctrl-C.
Might be easier to ask for the network and mask all in 1 prompt - I think users are quite used to entering syntax like 192.168.48.1/24 all in 1 prompt these days. Then it can be validated straight away and easily re-prompt if the input is invalid.

Actions #7

Updated by Phillip Davis over 10 years ago

As a side-issue, I purposely put in dodgy values for the DHCP - outside of the subnet I had specified - and was surprised that it did not complain. Should the DHCP range also be validated and forced to be inside the specified subnet? Or is there some use case here with DHCP-relay where the user might have a real need at the console to set a DHCP range outside the subnet?

Actions #8

Updated by Jim Pingle over 10 years ago

  • Status changed from Feedback to New
Actions #9

Updated by Phillip Davis over 10 years ago

Latest changes for the console work nicely - it re-prompts for the IPv4 address when the address and netmask combination are invalid. One little cut-paste bug in validating the DHCP range, fixed by https://github.com/pfsense/pfsense/pull/861

Actions #10

Updated by Renato Botelho over 10 years ago

  • Status changed from New to Feedback
Actions #11

Updated by Phillip Davis over 10 years ago

I can't break it now - the console interface is validating lots of IP subnet and DHCP range stuff... Since I did the latest couple of code changes, maybe someone else should give it a spin for an independent test.

Actions #12

Updated by Renato Botelho about 10 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF