I have not kept my VCDX ambitions in the dark. Well, come December 2nd last year I submitted my design for VCDX NV. The VCDX is VMware’s highest certification for individuals and focuses on four tracks – these currently are Data Center Virtualisation, Network Virtualisation, Desktop Management, and Cloud Management Automation.
Journey thus far
I have done a few design now for NSX for vSphere and it gave me the confidence to mould an existing design to the handbook and blueprint requirements. It is key that someone attempting VCDX-NV knows and understands the blueprint for their respective track. Understand what is expected, understand what is required, and most importantly, know your design.
I create my own template for my documents in a modular fashion which was logical to me and my reader. Given that NSX touches many components of the stack
Mock, Stock, and Two Smoking VTEPs
I submitted my design as previously mentioned and this was successful with all required documentation met and received. This was a great email to receive after submissions as I battled some work commitments, personal commitments, and a state-side trip all within 2 weeks of the submission date. It was hectic and at many times I felt that I forgot something but I did not.
Now it is time to prepare my presentation and run some mock presentations through that explain my design along with defending my decisions that I made. My defence date is mid February and it is all eyes are set to that. Between now and then I have a metric bucket-load of work which means my time on this must be focused and precise.
What stands between me and VCDX is something I do on a regular basis – make decision based upon information I have at hand, discuss it, and move on.
They have my numbers and it is time to claim them.
The customer ask
I had a customer ask a good question about Distributed Firewall rules and if they’re enforced on NSX Edges. The customers interpretation of the two enforcement points made it look like he had to maintain two sets of firewall rules – one set for a Distributed Firewall and the other on each NSX edge.
The difference in firewalls
The Distributed Firewall is a vNIC level firewall on the hypervisor kernel that protects each workload. The filter itself follows the workload anywhere as it is instantiated and enforced on the vNIC. The NSX Edge also has a rudimentary firewall filtering on egress and ingress.
Applying rules across all edges
The customer sought to adjust the default Edge firewall rules from a single point. Using the Web Client browse to Network & Security \> Firewall
I have made a ruleset here
- SRC IP Set
- DST mgt-sv-01a
- Port RDP
- Action Block
By default this would be applied to the Distributed Firewall after saving the ruleset.
I need to enforce this across all edges as per the original request. This can be done by modifying the Applied To field. By checking the box that states “Apply this rule on all the Edge Gateways” it will enforce this onto all NSX Edge Firewalls.
Alternatively you could select the Edges that are pertinent to a customer or application topology. This can be done by not Applying to All and calling out the individual objects.
The result under the Firewall management panel looks something like this.
To validate that it is applied browse to the relevant Edge you have enforced the rule on. Networking & Security \> NSX Edges and in this case, double click on Edge-Gateway-01. Select the Firewall tab. The result should look something like this
You will find the rule is faithfully represented and enforced on the edge.
If you just apply rules to the Distributed Firewall only you will get enforcement on ANY workload that matches the criteria across the entire NSX domain. If you want to enforce based on a different object type such as Security Group have a look at this blog entry.