SonicPoint provisioning - how to influence the IP address assignment by the Firewall (an exampl

03/26/2020 18 12611

DESCRIPTION:
SonicPoint provisioning - how to influence the IP address assignment by the Firewall (an example of subnetting and alternative SonicPoint ip address allocation)

RESOLUTION:

This article aims to provide an explanation to how the SonicWall administrator can influence the IP address assignment by the UTM firewall .
For a guide on "SonicPoint provisioning: how to influence the IP address assignment by the UTM firewall controller", please refer to KB 9345

The SonicWall administrator cannot choose the ip address to be assigned to each and every SonicPoint connected to a WLAN interface, as the provisioning is completed by the firewall controller, which assigns IP addresses to SonicPoints according to the following criteria:

1. the IP address pool is taken from the WLAN network configured on the interface where the SonicPoints are connected;
2.  if the WLAN is segmented into VLANs, then the SonicPoint ip addresses are taken from the management network (or native VLAN);
3.  the number of ip addresses reserved for the SonicPoints is determined and configurable by means of the "SonicPoint limit" parameter, which is configurable in the WLAN physical interface "General" configuration tab
4.  the ip address assigned to the SonicPoints is taken from the slot: [(254 - SonicPoint_limit) to 254] belonging to the given subnet (see points 1 and 2)

Aforementioned criteria are explained with examples and screenshots from the SonicWall SonicOS Enhanced gui in KB 9345.

In KB 9345 an example of provisioning and ip address assignment is shown: after

• configuring data vlan on sub-interfaces belonging to physical interface X4 (10.20.0.1/24);
• choosing SonicPoint Limit = 4 from Network/Interfaces/x4_configure/General_tab;
• linking the SonicPoint behind interface X4;

the SonicPoint N is assigned the first ip address (i.e. 10.20.0.251) in the slot available (10.20.0.251 - 10.20.0.254), this in case he choose to have a WLAN without VLANs (Virtual Access Points).



It is recommendable not to use a SonicPoint Limit number too much greater than the actual number of SonicPoints to connect, in order not to have too many unnecessary ip addresses reserved on the impacted network.

Nevertheless the SonicWall administrator may have already allocated one or more of the ip addresses to resources in the network (server, printers, etc..).

How can then the SonicWall administrator workaround this issue without reconfiguring at IP level the subnet, for a WLAN without VLANs (Virtual Access Points)?

The SonicWall administrator can identify a spot in his subnet free of ip address assignments, large enough to allocate the ip addresses of all SonicPoints on the given subnet.

In this case, we present an example of subnetting and alternative SonicPoint ip address allocation.

Data from case study:

• UTM Appliance: NSA 2400
• WLAN Subnet:10.20.0.0/24
• WLAN X4 ip address:10.20.0.1
• Number of SonicPoints to dedicate to X4: 4
• No Virtual Access Points configured
• ip address slot available on a pre-existing network, for SonicPoints:
  
  1. 10.20.0.30 - 60
  2. 10.20.0.100 - 120
  3. 10.20.0.230 - 250

Summary and considerations on the Data from case study:

• The UTM NSA 2400 supports up to 32 SonicPoints linked to an interface;
• No Virtual Access Points configured, means no VLANs, meaning that management and data traffic is on 10.20.0.0/24
• Only ip address range 3 can be used to allocate ip addresses for the SonicPoint provisioning, because the ip address assigned to SonicPoints is taken from the slot: [(254 - SonicPoint_limit) - 254] belonging to the given subnet, and since the NSA 2400 supports a maximum of 32 SonicPoints (as in figure below), so the lower ip address than can be allocated in the given subnet is 10.20.0.223 (please refer to KB 9345 for more details).

Case study resolution

• Configuration of 16 SonicPoints from the SonicWall gui (SonicPoint Limit = 16 from Network/Interfaces/x4_configure/General_tab);

In this way the SonicWall will reserve subnet slot 10.20.0.239 - 10.20.0.254 for provisioning 16 SonicPoints, and will start the assignment from 10.20.0.239, so that the 4 SonicPoints will be provisioned in the slot 10.20.0.239 - 10.20.0.242, which is included in slot 3 of the data case study.

As long as the number of SonicPoints physically linked to X4 will be stable (e.g. 4 in this case) no other arrangement are requested to the administrator.
The administrator has anyway be cautious if adding other SonicPoints, because the ip address will be allocated in an "increasing slot" that may stretch to ip address already allocated to other resources. In this example, the customer can safely add up to 12 SonicPoints, saturating the slot between 10.20.0.239 - 240, but the 13th SonicPoint will not be provisioned, because 10.20.0.251 - 254 are ip addresses already assigned to other resources.