Site icon CormacHogan.com

Creating firewall rules in NSX to control client access to DSM provisioned databases

This post began as a request from one of our customers. They wanted to know how one would go about allowing a select set of clients access a select set of databases provisioned by Data Services Manager, whilst simultaneously preventing access to other databases. I put my head together with my DSM buddy Thomas and came up with the following solution. We thought it interesting enough to share in a blog post, but we may also put this into the official DSM docs as well. Whilst this is using VCF 9.0 and new constructs such as VPCs and VPC subnets, the same steps can be used with other networking constructs.

Let’s begin with a diagram showing what we want to achieve. In a nutshell, I want the clients (VMs with users using the psql or pgAdmin tool to connect to the database) on client segment A (my team A) to be able to access Postgres databases provisioned onto database network segment A (whitelist). I do not want team A to be able to access databases on database network segment B (blacklist).

Let’s see how to achieve this. First of all, in my VPC, I am going to create two VPC subnets, one for team A and the other for team B. These will be assigned different CIDRs. The first is 10.196.0.128/26 with a gateway set to 10.196.0.129. This same range of IP addresses will be used by DSM for the IP Pool to provision databases for team A.

The second VPC subnet is 10.196.0.192/26 with a gateway set to 10.196.0.193. Similarly, this range will be used by DSM is a different IP Pool for team B.

The next step is to create the two IP Pools mentioned earlier, matching the IP address ranges in the different VPC subnets. Here is IP Pool for databases provisioned by team A, which matches the VPC subnet for team A.


And here is IP Pool for databases provisioned for or by team B, which matches the VPC subnet for team B.


Finally, we can create two Infrastructure Policies, each containing a different IP Pool. Team A would use one of the infrastructure policies to provision its databases, whilst team B would use the other one.

Now, at this point in time, without any NSX Distributed Firewall (DFW) rules in place, my client VM can reach databases provisioned on both team A and team B networks. Here is an example taken from a client that is on a completely different client network segment as shown on the opening diagram. As you can see, this client can connect to both the database on database network segment A and a database on database network segment B. This is because there are no rules in place to prevent access.

I need to create a new DFW Policy with some rules which will allow only connections originating from my clients to connect to the database on the team A database network segment. Those rules might look similar to the following, allowing my client’s IP address to access database network segment A, but blocking it from reaching database network segment B

Let’s repeat the connection string test done previously. Now we can see that my client can no longer reach the database on database network segment B.

This is a very simplified demo, but hopefully it gets the idea across that you can control access between clients and databases through the use of NSX DFW rules. You could of course lock down the access even further by only allowing the Postgres port (5432) open between the client and database network segments. When considered with custom certificates and host based access rules, the latter defining which users can access a database from which network, it is possible to design a very secure DBaaS using DSM with NSX DFW and VPCs in VCF 9.0.

Exit mobile version