The topology below depicts a standard three tier application comprised of a web front end with a load balancer, application tier and a database backend. Each tier is a separate IP subnet on a logical switch connected to a logical router. The logical router is connected to the NSX edge. The edge instance provides connectivity to the outside network and can provide additional routing, NAT and VPN services.


To secure this workload an administrator has configured the following rules under the firewall tab in the vCenter server.

Action Source Destination Service
1 PERMIT Web Logical Switch 80,443
2 PERMIT Web Logical Switch App Logical Switch 80,443
3 PERMIT App Logical Switch DB Logical Switch SQL
4 DENY Web Logical Switch Web Logical Switch 80,443
5 DENY Web Logical Switch DB Logical Switch All
6 DENY Any Any All

The table above outlines the sample rules used in this topology.


The administrator would configure the rule sets listed above. The moment the rules are created and subsequently saved, the configuration is pushed down from the vCenter Server and into the kernel of all NSX enabled clusters. This change can be committed immediately or at a later time. Very similar to the JUNOS feature commit or commit at.

It is important to know what the rules are and what they are exactly enforcing.  The diagram below takes a look at how the sample traffic flows are enforcing and where they are enforcing.


  1. Rule 1 permits a range of existing IP addresses to access the Web Logical Switch – load balancer VIP – on ports 80 and 443 (HTTP,HTTPS). All other ports denied and sources denied.
  2. Rule 2 permits the Web server to perform a lookup to the Application Tier. This permits the source Web Logical Switch (VXLAN VNI 5000) to Application Logical Switch (VXLAN VNI 5010). This is an example of a vCenter object rule matching.
  3. Rule 3 permits the Application Logical Switch (VXLAN VNI 5010) to the Database Logical Switch (VXLAN VNI 5020) for SQL traffic. This is an example of a vCenter object rule matching.
  4. Rule 4 denies all traffic from the Web Logical Switch (VXLAN VNI 5000) to the same Web Logical Switch (VXLAN VNI 5000).
  5. Rule 5 denies all traffic from the Web Logical Switch (VXLAN VNI 5000) to the Database Logical Switch (VXLAN VNI 5020).
  6. There is an implicit deny at the any that blocks any source, any destination and any service.

The rule sets of particular note are Rules 1, 2 and 4.

  • Rule 1 matches based on traditional IP addressing allowing a source IPs that a destined to the Web Logical Switch network segment with the VNI of 5000 .
  • Rule 2 permits any virtual machines attached to the Web Logical Switch VNI 5000 to communicate with any virtual machines attached to the Application Logical Switch VNI 5010 on port 80 and 443.
  • Rule 4 denies all traffic from Web Logical Switch to Web Logical Switch. This rule is stops Web Virtual Machines talking to other Web Virtual machines. Web Virtual Machines may be internet facing and require a reduced attack vector. If a web machine is compromised this rule restricts the lateral attack vector.

This is an excerpt of a paper I am currently writing based on application tiers and how to enforce segmentation. This actually is PCI-DSS complaint too which is great as we know how stringent PCI compliant environments are. Whilst workloads still reside on L2 segments and have isolation it is possible to take something like this further and collapse this into a Micro Segmentation architecture. This would have a traditional three tier app on one L2 segment using firewall policy to enforce security tiers. I’ll save that one for another post soon and hopefully my VMworld session.

One thought on “Virtual firewalls and 3 Tier apps

Leave a Reply

Your email address will not be published. Required fields are marked *