The next step is to allocate all or part of those CIDR ranges to a sub-interface to further refine the scanning process.
In the figure below, we are adding a sub-interface called Feedback_Center, assigning it the Default Testing, and allocating only the IP address of the Feedback Center to it. To specify a single host, you use a 32-bit network mask:
.png "GUID-96B83CF9-B5A6-4F00-B4E9-78BDDB22D9F3-low.png")
The key to successfully allocating multiple subnets from a single CIDR range is that the corresponding sub-interfaces cannot overlap. As obvious as it might sound that you cannot allocate all or part of a CIDR range multiple times, the flexibility of CIDR addressing can sometimes also make the calculations confusing.
If you attempt to use a CIDR range multiple times, the user interface will return an error. Let's step through an example to produce such an error.
At this point in the configuration process, the entire 192.168.0.0/24 CIDR range is available for sub-interfaces, except the 192.168.0.12 IP address (which is the IP address of the Feedback Center).
In the figure below, we are allocating the 192.168.0.128/25 range as well via a sub-interface called Test_1 and assigning the Default Prevention policy to it. Otherwise put, this will allocate the IP range from 192.168.0.128 to 192.168.0.255.
.png "GUID-E4D53E58-4032-44CB-A5C3-964BA974DFB3-low.png")
If we next attempt to allocate 192.168.0.1/25, we will receive the following error:
.png "GUID-56197734-A854-4CA3-B08E-A6AD0AF473D4-low.png")
The reason for the failure is that 192.168.0.0/25 allocates the IP range from 192.168.0.0 to 192.168.0.127, which includes the previously allocated IP address of the Feedback Center 192.168.0.12, so this is an overlap. The error is explaining that the sub-interface was created, but no CIDR range was actually allocated to it.
If you need a reality check while in the process of creating or editing a sub-interface, you can always view the list of currently allocated CIDR ranges.
If we discard the third sub-interface (the one that returned an error, i.e., Test_2) and look back at the details of the interface, a few things have changed.
The output for the network will look as follows:
.png "GUID-0E08C140-8A60-4705-B771-F0952178BB5C-low.png")
The IPS Interfaces includes an icon for each new sub-interface.
Parts of the 192.168.0.0/24 CIDR range are now shown in the Properties page to be associated with the new sub-interfaces (and, therefore, their policies).
The details of the final configuration are as follows:
Traffic from or to IP addresses ranging from 192.168.0.128 - 192.168.0.255 will have the Default Prevention policy applied to it.
Traffic from or to the Feedback Center (192.168.0.12) will have the Default Testing policy applied to it.
Traffic from or to any other IP in the 192.168.0.0/24 CIDR range or the 10.0.0.0/8 CIDR range will have the DMZ policy applied to it.
Traffic not containing any of those IP addresses will have the default policy applied to it (the policy assigned to the Sensor).
We could, for example, create another sub-interface for all or part of the 10.0.0.0/8 CIDR range. If we subsequently wanted to allocate yet another CIDR range to a sub-interface, we would first have to add that range to the G3/1-G3/2 interface.