In production deployments it is common for multiple different sites to have the same IP spaces used. This creates a problem in differentiating traffic to the same IP space that is intended for different locations. For example, Site A is using the subnet space of 192.168.0.0/24 and Site B is using that same subnet space. There are 2 main options for differentiating this IP space between sites.

Option 1 is to designate a group of users whose traffic to 192.168.0.0/24 is directed to either Site A or Site B (in this case we will assume Site A). This means that these users have no change to their day-to-day workflow, but are not able to access 192.168.0.0/24 at Site B (without combining Option 2, which is discussed later). Users can be added and removed from this group dynamically by an administrator. So, our user (User A) in this example may only be able to access Site A, but User B can be designated to access site B using the same IP.

These groups are managed by adjusting the assigned source IP for a user in a region in the Dispel console. These groups are normally broken into /24 subnet blocks in the user IP space, which is 10.8.0.0/16 by default. To continue our example, let's say Site A's user group is 10.8.10.0/24. In image below Matt is added to the 10.8.10.0/24 user group and will access Site A, while Waylan has a standardly assigned IP (IPs are assigned in order from least to greatest by default), is therefore in no group, and will access Site B.

To update a user's IP you can simply click on the IP in the console, enter the desired IP and click "Update IP"

The advantages of Option 1 are that it is invisible to the user in scenarios where they only need to access one of the 2 sites, allowing for a smoother and simpler end-user experience. Also, it is a one time setup in scenarios where a user only needs to access one site.

The disadvantages of Option 1 are that each user must be configured individually, and it prevents users from accessing both sites simultaneously on the overlapping subnet. Notably, both sites are still accessible outside of the overlapping subnet(s).

Option 2 is to designate a separate subnet for one of the overlapping subnets. Continuing our example from Option 1 -- in this case we may decide to designate Site B to be accessed through 192.168.2.0/24. This means if a user wishes to access the device "192.168.0.1" at Site B, then they will need to input "192.168.2.1" from their VDI. In this scenario Site A is accessed normally.

Option 2 can be used in combination with Option 1 to create a seamless flow for users who need to only access one site, and a backup option for users who need to simultaneously access multiple sites with overlapping subnets. To continue our example above, let's add another site "Site C", which also uses the 192.168.0.0/24 network space. With option 2 we can designate Site A to be accessed with 192.168.1.0/24, Site B to be accessed with 192.168.2.0/24 and Site C to be accessed with 192.168.3.0/24.

However, if there are users who need access to only 1 of the 3 sites, user groups can be created with option 1 to allow these users to access using the IP spaces they are familiar with (in this case 192.168.0.0/24). Also, if users in a group still need to access the other sites, then they are still able to access them with their respective designated IP spaces. For example, a user is in the 10.8.10.0/24 subnet group that is designated for Site A, but this user wishes to access a device in Site B. They can still use that device's IP in the 192.168.2.0/24 subnet space to reach it.