VMware vCloud Networking and Security Edge is part of the vCloud Networking and Security solution and provides network edge security and gateway services such as DHCP, VPN, NAT, Firewall and Load Balancing. In an earlier post here, I described how to deploy SNAT and DNAT using Edge and briefly touched upon the firewall capabilities. In this blog, I will go through firewall capabilities of Edge in detail.
Each Edge virtual appliance can have a total of ten uplink and internal network interfaces. The internal interfaces connect to internal port groups and act as the gateway for all protected virtual machines in the port group. Uplink interfaces of Edge connect to port groups that have access to a shared corporate network or Internet. Firewall rules and other Edge services are enforced on the traffic between interfaces.
In the three-tier application below, Web, App and DB tiers are on three different internal interfaces of the Edge. Uplink interface is connected to 10.20.181.0/24 network with access to corporate network. I have setup a Win7Client on another internal interface to test the three-tier application.
VMware vCenter view of Edge interfaces with the three-tier application is shown below.
The route table on the Edge is populated automatically as per the interface addresses configured (shown below). We can login to the Edge from vCenter console or using SSH. By default the Edge has the following firewall rules, these rules are created during Edge deployment as per the directives provided. Rules 1 & 2 are created as “Enable auto rule generation” shown below was checked during deployment. Rule 1 is allowing all the traffic initiated by Edge and Rule 2 is allowing the High Availability (HA) heartbeat traffic between active and standby Edge instances.
When Enable auto rule generation not checked, we must manually create firewall rules to add firewall, NAT, and routing routes to allow control channel traffic for Edge services such as Load Balancing, VPN, etc. Auto rule generation does not create rules for data-channel traffic. If Enable auto rule generation was not checked during deployment, it could be enabled later using “Enable Auto Rules” from Actions menu as shown below.
Rule 3 was created during Edge deployment as per the selections shown below.
With the Rule 3 in place, the data traffic between all the edge networks is blocked by the Edge firewall. Following firewall rules need to be setup to open the required ports and protocols for the three-tier application to function properly and for Client-Network to access the web servers.
Allow HTTP and HTTPS traffic to Web Servers (Rule: Allow-Web-Traffic)
Allow Web Server to Application Server traffic on port 8080 (Rule: Allow-Web-To-App)
Allow Application Server to Database Server traffic on port 3306 (Rule: Allow-App-To-Db)
Allow-Web-Traffic Rule
In the example above, “Web-IPs” is a Grouping Object with IP addresses 192.168.1.2 and 192.168.1.3. Grouping Objects are used to represent a collection of IP addresses, MAC addresses, or a security group containing other Grouping Objects. List of object groupings created in this setup are shown below. The Grouping Objects with name starting with “internal” are pre-defined by Edge firewall.
Services and Service Groups are used to represent ports and protocols used in rules. Sample services defined in this setup are shown below. Majority of the services listed below are pre-defined for convenience and ease of use.
Another nice feature that can be used for Source and Destination conditions is a VnicGroup. In the example below, the web traffic is allowed only from VMs connected to internal port groups.
All the rules defined for the three-tier application communication are shown below.
Once these firewall rules are published, Win7Client (192.168.4.2) on Client-Network can access the web servers 192.168.1.2 and 192.168.1.3 using HTTP and HTTPS, web servers can communicate with application server (192.168.2.2) on port 8080 and application server can communicate with database server (192.168.3.2) on port 3306.
With logging enabled on firewall rules and a syslog server configured for the Edge, following syslog messages are shown illustrating firewall rules are working as configured.
HTTP (port 80) traffic accepted from Win7Client (192.168.4.2) to Web Server (192.168.1.2) HTTPS (port 443) traffic accepted from Win7Client (192.168.4.2) to Web Server (192.168.1.3)
Port 8080 traffic accepted from Web Server (192.168.1.3) to Application Server (192.168.2.2)
Port 3306 traffic accepted from Application Server (192.168.2.2) to Database Server (192.168.3.2)
Another nice thing to notice in the syslog messages is the Rule Tag field to correlate with the actual rules. 131101, 131098, 131099 in above messages are the Rule Tags and they are show in the Firewall rule table below. Some of the columns in Firewall rule table are not visible by default, we can enable them as shown below.
The route table on the Edge is populated automatically as per the interface addresses configured (shown below). We can login to the Edge from vCenter console or using SSH. 
By default the Edge has the following firewall rules, these rules are created during Edge deployment as per the directives provided. 
Rules 1 & 2 are created as “Enable auto rule generation” shown below was checked during deployment. Rule 1 is allowing all the traffic initiated by Edge and Rule 2 is allowing the High Availability (HA) heartbeat traffic between active and standby Edge instances.
When Enable auto rule generation not checked, we must manually create firewall rules to add firewall, NAT, and routing routes to allow control channel traffic for Edge services such as Load Balancing, VPN, etc. Auto rule generation does not create rules for data-channel traffic. If Enable auto rule generation was not checked during deployment, it could be enabled later using “Enable Auto Rules” from Actions menu as shown below.
Rule 3 was created during Edge deployment as per the selections shown below.
With the Rule 3 in place, the data traffic between all the edge networks is blocked by the Edge firewall. Following firewall rules need to be setup to open the required ports and protocols for the three-tier application to function properly and for Client-Network to access the web servers.
In the example above, “Web-IPs” is a Grouping Object with IP addresses 192.168.1.2 and 192.168.1.3. Grouping Objects are used to represent a collection of IP addresses, MAC addresses, or a security group containing other Grouping Objects. List of object groupings created in this setup are shown below. The Grouping Objects with name starting with “internal” are pre-defined by Edge firewall.
Services and Service Groups are used to represent ports and protocols used in rules. Sample services defined in this setup are shown below. Majority of the services listed below are pre-defined for convenience and ease of use.
Another nice feature that can be used for Source and Destination conditions is a VnicGroup. In the example below, the web traffic is allowed only from VMs connected to internal port groups.
All the rules defined for the three-tier application communication are shown below.
Once these firewall rules are published, Win7Client (192.168.4.2) on Client-Network can access the web servers 192.168.1.2 and 192.168.1.3 using HTTP and HTTPS, web servers can communicate with application server (192.168.2.2) on port 8080 and application server can communicate with database server (192.168.3.2) on port 3306.
HTTPS (port 443) traffic accepted from Win7Client (192.168.4.2) to Web Server (192.168.1.3)
Port 8080 traffic accepted from Web Server (192.168.1.3) to Application Server (192.168.2.2)
Port 3306 traffic accepted from Application Server (192.168.2.2) to Database Server (192.168.3.2)
Another nice thing to notice in the syslog messages is the Rule Tag field to correlate with the actual rules. 131101, 131098, 131099 in above messages are the Rule Tags and they are show in the Firewall rule table below. Some of the columns in Firewall rule table are not visible by default, we can enable them as shown below.
