Choosing subnets

Before creating the children, it makes good sense to have some good idea of what subnets will be used. This might have been a task that has been largely put off, because there was a greater desire to be focused on simply creating a virtual machine. However, the next steps will involve creating more machines. This guide is designed to show how to make one of those machines serve as a firewall. (Whether you do that in your own implementation is something that is up to you, unless you are following this guide as part of a formal structure like classroom training, in which case the decision may have been made by somebody else with the authority to make that decision. Regardless of whether you follow that aspect of the guide's task list, the fact remains that creating such a computer, or at least being able to do so, was part of the guide's design.)

Check instructions

A network administrator may provide some network addresses to use. If there are instructions in addition to this guide (such as if this guide is being followed as part of a formal course), then see if instructions have been provided regarding what subnets to use. (A subnet is simply a range of addresses. So, this is saying to check for what addresses to use.)

If instructions have been provided, make sure to follow them.

For now, the network layout documentation has not been posted. (At the time of this writing, that documentation is under review. It may be changed substantially before getting used by this document.)

It may be helpful to review network designs. Following is a sample. For a visual diagram of where these pieces go, see: CHECK HYPERLINK network layouts: Quad NIC svr.

[#pfwsbnet]: Subnet requirements

This guide describes the creation of multiple subnets. Note that this list can certainly be customized by experienced people who know what types of changes they wish to make. However, this list is simply describing what subnets will be created when using this guide to create a specific layout, which is described by CHECK HYPERLINK a network layout for a Quad NIC svr.

External subnet

Broadband Modem gets one IPv6 address and one IPv4 address. The extNIC0 gets one IPv6 address and one IPv4 address.

Outside VM NIC subnet

tunext_nic4 gets one IPv6 address and one IPv4 address. The fw_ext_nic0 gets one IPv6 address and one IPv4 address.

Inside VM NIC subnet

tunint_nic5 gets one IPv6 address and one IPv4 address. The fw_int_nic1 gets one IPv6 address and one IPv4 address.

vmSvrs subnet

fw_vm_nic2 gets one IPv6 address and one IPv4 address. (That NIC is part of a virtual machine.) Also, every other virtual machine gets one IPv6 address and one IPv4 address.

There are 5 virtual machines shown in the drawing, so that is 12 IP addresses. (1 IPv6 for fw_vm_nic2, 5 IPv6 addresses for the other virtual machines, and 6 IPv4 addresses that are assigned to the same network interfaces as those 6 IPv6 addresses).

internal wired LAN
In this example, plan for 6 devices.
Wi-Fi
The drawings show 2 devices. In this example, plan for 6 devices.
TrustedLAN
The drawings show one device (a NAS). In this example, plan for 6 devices.

So that is three subnets (Outside VM NIC subnet, Inside VM NIC subnet, External subnet) that need 2 devices each. One subnet really needs a few more devices, so that subnet (named vmSvrs) supports up to 6 devices. Three more subnets (internal wired LAN, Wi-Fi, and TrustedLAN) could get by with as little as four addresses for a small network that doesn't have much room for expansion.

If vmSvrs supports 6 devices, and all of the other IPv4 subnets are /30 subnets, then all of these subnets can fit within a single IPv4 /27. Limiting the available addresses to a single IPv4 /27 provides little benefit if this is the only network being used in an organization, but a formal classroom environment may prefer to be using relatively small subnets so that multiple students are using addresses that are rather close to each other. Staying within the limit of a /27 for each network would allow up to eight /27 networks within a single /24 address space.

[#dmosbnet]: Subnets used by this guide

This documentation is going to use the following:

External subnet
Outside VM NIC subnet
Inside VM NIC subnet
vmSvrs subnet
internal wired LAN

Note that these subnet sizes are being used for demonstration purposes, demonstrating just how few addresses are needed. (The Outside VM NIC subnet, Inside VM NIC subnet, vmSvrs, and internal wired LAN could all fit on an IPv6 /123 (with a 126 to spare)if the content between the second and third colons were made identical. Similarly, all those same subnets could fit in a IPv4 /27 with a /30 to spare.)

For actual deployment, sizes of IPv4 /25 or larger may be more reasonable. Larger subnets have more host bits, which means smaller numbers after the slash (which means fewer network bits, allowing more host bits), so IPv4 /24 would be a larger subnet. For IPv6, /64 is reasonable and a rather common subnet size.

Wi-Fi

Note that an IPv4 /29 is just being used for demonstration purposes, to show how this could be done in a situation where addresses are crammed into small address spaces. For an actual deployment, using /26 (netmask 255.255.255.192) or /24 may be more reasonable.

  • (IPv6 2001:db8:3:: /64 will be used for un-authenticated Wi-Fi)
  • (IPv4 192.0.2.128 /29 will be used for un-authenticated Wi-Fi. That could also be bopped up to 192.0.2.128 /26.)
TrustedLAN

That being said, it is recommended that people following this guide do NOT use those addresses. (The reasons are described right after this section.)

That's right. Please don't use those addresses. This guide is properly using those addresses, because those addresses have been reserved for use by documentation and examples. That's exactly what this guide is. However, in actual practice, it is recommended to use other subnets. By not using these addresses, people may become familiar with these address as being samples/examples that are often used in documentation. Technicians who have experience with these addresses can quickly identify these addresses. So if there is an attempt (which is presumably accidental) to actually use the address, the experienced technicians can quickly identify that these addresses weren't customized. That may help to speed up some troubleshooting efforts. Officially, these addresses are meant for documentation. Unofficially, it may make sense to think of them as addresses that haven't been customized yet, which typically indicates that a computer that is trying to use such an address will still need to be customized before it properly uses a customized address.(That felt a bit convoluted, and has probably been documented better elsewhere.)

For IPv6, many people recommend using publicly accessible IPv6 addresses. For IPv4, that is often impractical, and so people typically use addresses specified by IETF BCP 5: private IPv4 addresses, more famously known as RFC 1918 addresses. A similar approach can be done with IPv6 by having the address start with the hexadecimal digits “fd”. (A process for doing so is noted by RFC 4193 section 3.2.2. The address range was reserved by RFC 4193 section 3.1 by referencing addresses in fc00::/7 which have the eighth bit set to 1, which equates to the fd00::/8 subnet.) An IPv6 address that follows that guideline (starting with “fd”) is called a “unique local address” (“ULA”). Some network enthusiasts/professionals have spoken strongly against the use of IPv6 ULAs. For that matter, private IPv4 addresses also had some opposition, but usage of private IPv4 addresses is extremely widespread to limit the number of public IPv4 that have needed to be used. Since IPv6 has many more addresses, that hasn't been a problem.

Selecting a subnet

As an example of how this can be done:

Pick a private address from the range provided by IETF BCP 5: private IPv4 addresses, more famously known as the RFC 1918 address range. For example, 172.18.47.215. Ideally, the address chosen will be one that is less likely to be used by others; this can be done using a rather systematic method (see ###netadrpl ), or the method may be something a bit more random. In this case, the address was chosen partly at random, although it was also chosen based on the fact that trying to use this address will cause a minor issue with a later step.

See a VLSM chart. ][CyberPillar]['s VLSM chart really is a good one, and making subnets has a “VLSM charts” section that provides hyperlinks to some others.

Then, figure out how big the desired subnet will be. For IPv6, a safe answer is /64. For IPv4, /24 is often a good choice, although one may wish to use a smaller subnet such as an IPv4 /27. (Larger numbers after the slash means that there are more bits that identify the network, leaving fewer bits for host identification, and that results in smaller subnets.) We'll go ahead and use /27 as an example.

Note: The IPv4 subnet's size should be large enough to contain the enough IP addresses for every computer/device that will be part of the subnet. So, if each device will use one IPv4 address in the subnet (which is extremely common), and if there are 5 devices, then the subnet size needs to have at least 5 usable addresses. The easy way for a beginner to identify how many addresses are in a specific subnet is to look at one of the VLSM charts. A VLSM chart will show there are thirty two addresses in each IPv4 /27. The first address and the last address of each IPv4 subnet are typically considered to be “unusable”. (Further discussion about these addresses being “unusable” may be found from the glossry entry for “network ID”) Thirty two, minus two unusable addresses, leaves thirty usable addresses in an IPv4 /27.

Since five devices are planned, that subnet is a bit larger than necessary. With this example, we could go down to an IPv4 /29, which provides six usable addresses. However, since there are already plans to use up five of those addresses, perhaps an IPv4 /28 is a more sensible compromise. That will allow some expansion, so that another couple of systems can be added. Note that some people might just choose to use an entire IPv4 /24. That may be a bit more frivolous, but that is often very acceptable when people are using private IPv4 addresses. A /24 is often a rather convenient size.

Use the VLSM chart and the pre-chosen address to identify a subnet. So, for example, the address that was chosen (rather randomly) was “172.18.47.215”. Just take the last octet, which is “215” in this example. On the VLSM chart, find the subnet that is the chosen size (a /28 was decided upon, earlier) and which involves the number “215”.

The subnet which involves that address is the subnet that includes the addresss from 208 through 215.

Actually, since 215 is the last IPv4 address in this subnet, that address is generally considered to be “unusable”. (This is mentioned by ###broadcast address ). If the chosen address was 208, then the address would also have been unusable, because it would be classified as the IPv4 “network ID”. Further discussion about these addresses being “unusable” may be found from the glossry entry for “network ID”.

One way to resolve this could be to increase the subnet size; subnets larger than /28 don't have a subnet ending with 208, which can be seen from the VLSM chart. Another method is to simply choose a different address. So, insetad of “172.18.47.215”, the device will use “172.18.47.212”. That will work fine.

Note that there is no current need, at this time, to figure out every single computer's address. (That will be a need in the near future, but it is not an immediate need.) What is needed, though, is to figure out which subnets are going to be in use.

Selecting multiple subnets
Cramming into a /27

The process of identifying a subnet may have seemed a bit complex, especially for something that needs to be done five times over. But, really, it doesn't need to be very hard.

Consider the following example: an instructor tells a student to select subnets from within a single /27 in order to fulfill the subnet layout for physical firewall. For a moment, this guide recommends focusing less on how the conclusions are reached, and just think about whether the resulting conclusions seem complicated or simple.

In this example, the student uses an assigned /27:

External subnet

IPv4 192.168.0.0/30
IPv6 fd:: /64

Outside VM NIC subnet
IPv4 192.168.0.4 /30
IPv6 fd40:: /64
Inside VM NIC subnet
IPv4 192.168.0.8 /30
IPv6 fd80:: /64
vmSvrs subnet
IPv4 192.168.0.16 /29
IPv6 fdf0:: /125
internal wired LAN
IPv4 192.168.0.24/30
IPv6 fd1c:: /125
Wi-Fi
IPv4 192.168.0.28 /29
IPv6 fd20:: /64 (IPv6 fd1f:: /64 will be used for un-authenticated Wi-Fi)
TrustedLAN
IPv4 192.168.0.12 /29
IPv6 fdc0:: /64

The important details for the IPv6 subnets are that they start with “fd” and they are unique. The main thing that takes a bit more effort is cramming the IPv4 addresses within the permitted space. Since the “vmSvrs” subnet needs to support 5 systems, a /29 was used.

Here's a basic visual depiction of the subnets that were chosen. (This doesn't show the names of the subnets; it just shows the /27 in the left column, and then shows the subnet ranges in the other columns.)

0-310-3
4-7
8-11
12-15
16-23 
 
24-27
28-31

So, here's the big question: If you look at a VLSM chart, and are told which specific /27 to use, then do you have the ability to find an available /29 and six /30 subnets, without any of the addresses overlapping? In other words, if you were given 32 32 addresses, then could you use a VLSM chart to locate a block of 8 addresses, and then six other blocks of four addresses, chosen so that none of those addresses overlap?

That's what the process of subnetting involves. Determine how many addresses are needed in each subnet, and select subnets that fit the requirements. In this case, the requirements started with 32 addresses being available, and there were requirements about the other subnets.

Note: the “demonstration subnets” do not fit within a single /27 (but they do use less than 1 1/2 /27. That is because the “demonstration subnets” intentionally used some larger subnets, spreading out the addresses a little bit more. If you are not part of a class with many people, this guide recommends using subnets that are not smaller than the “demonstration subnets”, because that will allow a person to use multiple devices in some of the critical subnets, and permits a tiny bit of expansion. However, if this was done in a home network, where addresses are super plentiful, then the following layout might be even nicer:

file:///C:/users/user/cybr/dirsver/1/mainsite/techns/netwrkin/netistrc/netadrsn/netadrpl/netadrpl.htm#ip4adyrn
External subnet

IPv4 192.168.8.0/28
IPv6 fd:: /64

Outside VM NIC subnet
IPv4 192.168.16.4 /30
IPv6 fd40:: /64
Inside VM NIC subnet
IPv4 192.168.24.8 /30
IPv6 fd80:: /64
vmSvrs subnet
IPv4 192.168.4.16 /24
IPv6 fdf0:: /125
internal wired LAN
IPv4 192.168.12.24/24
IPv6 fd1c:: /125
Wi-Fi
IPv4 192.168.28.28 /25
IPv6 fd20:: /64 (IPv6 fd1f:: /64 will be used for un-authenticated Wi-Fi)
TrustedLAN
IPv4 192.168.20.12 /24
IPv6 fdc0:: /64

(Those subnets could have been chosen entirely at random, but they weren't. Some of those numbers were selected based on the following chart: “IETF RFC 3531”-based chart The reason why that chart was used was an attempt to NOT use the lowest 192.168 subnets, as noted by: “Do not start off by using: 192.168.0/24, 192.168.1/24, etc., nor 192.168.168/24”.)

As you can see, if flexibility exists, there can be multiple different results. When flexibility exists, there can be multiple possible answers which do things right. The main things to keep track of are making sure that subnets don't overlap, and making sure that subnets are at least large enough to fulfill requirements. When a student was told to try to fit everything into a single /27, then subnets were intentionally kept small, and the requirements were fulfilled. When requirements were less strict, the additional flexibility was used by choosing larger subnets. Those larger IPv4 subnets have more IP addresses, which will provide more ability to have more computers/devices join the network later on. Some of the IPv6 subnets were rather large, which is common for IPv6.

Choosing subnets based on TCP ports

If a person is using an IPv4 /25 subnet, there are 128 IPv4 addresses available (which can be seen by looking at one of the VLSM charts).

If a network administrator needed to choose two IP addresses from that range, then both addresses need to be within the range of 1 through 126. For the sake of using an example, let's presume that the servers are going to be used for E-Mail and website delivery. With more than 125 addresses to choose from, many of the network administrators would be rather inclined to make the same choice: 25 and 80. Why? Well, first of all, there's no compelling reason why they should use any other, different numbers. Second, those numbers match the standard TCP port numbers, as specified by IANA.

Since an average individual network administrator doesn't get to choose which TCP network ports are the Internet standards, they simply work with the choices that have already been made. They don't get to choose which TCP network ports are on IANA's list. What they may get to choose is the IP addresses that a device is using. What they decide to do is to make information match, because that is somewhat memorable. In truth, when a private IPv4 address ends with the octet of “.25” or “.80”, it is common to suspect that the machine may have one of those familiar services running on the machine.

If a /24 is used, then System Address Usage: “Some intital/early addresses” provides some options for the first fourteen addresses (.0-.13), and then ####sysadrfh first half of octet provides some additional addresses. Now, there is no compelling reason why the entire Internet should stick to that particular plan. It is, simply, just one plan that could be followed.

However, if you're going to use smaller subnets, then very often people may choose a subnet that involves using the .25 address for the SMTP server. Again, it will be pointed out that this is not some sort of requirement that the whole Internet feels obligated to follow. However, if you need to choose an IPv4 /29, then why not choose the one that uses the .24 - .31 addresses?

Similarly, there are other addresses shown by the system usage plan that was referred to just a moment ago. If you have other requirements, make sure to fulfill the requirements that you need to follow. If you're looking for a method that seems more sensible than just choosing numbers at random, that planning guide can be used. Using that guide may be an approach that makes sense to do, if there's no compelling reason not to.