Original design
This is the starting point of the infrastructure. A classic design that lot of enterprises have or used to have. Virtual Machine (VM) and Bare Metal Server (BMS) are sharing a same vlan behind a firewall. Everything begins when the VM wants to move to a more virtual infrastructure with distributed routing and firewalling. In this case they want to move to VMware NSXT.
From a physical point of view, the migration is performed on leaf and spine infrastructure that we will call the underlay. Every firewall interface is a different security zone that we will call DMZ. The aim of this blog post is to capture some thoughts around NSXT service interface design.
- Minus sign is what I consider as a cons while writing this blog.
+ Plus sign is what I consider as a pros while writing this blog.
There is no perfect solution, it always depends on the context and I might miss things so we can always discuss.
Some behavior that I currently consider as a cons can be a pros for the reader. This blog is really to capture what can be taken into consideration during the design phase and evaluate A couple of possible design scenarios.
Scenarios
Scenario 1 : Split DMZ / Multi DMZ
In this scenario we keep using the original firewall to protect the BMS and move all the virtual environment behind a new firewall interface creating a new DMZ
- Need to create new subnet for VMs.
- Need to have groups with /32 host in the firewall rules to avoid breaking the orignal flow between BMS and VMs.
- More rules, bandwidth and sessions than before on physical FW (because the original DMZ is now splited).
- BMS to VM traffic need to go through Edge + FW.
- Possibility to create a single segment for all VMs. Not necessarily a good idea.
+ We don’t touch BMS server, only VMs are impacted with this transformation.
+ Traffic from BMS to outside have to go only through FW compared to scenario 3.
+ No need of L3 interconnection with the underlay switch fabric like in scenario 2.
Scenario 2 : One VRF per firewall interface.
In this scenario we create a VRF in the underlay to attach the original subnet and the new virtual environnement. We are not creating a new DMZ (firewall interface) and we can benefit the microsegmentation of NSXT between the VMs vlan with mixed application or tier (link).
- As many VRF as firewall interfaces (DMZ).
- Need to migrate the vlan attached to the firewall interface to the VRF.
- More configuration on the underlay switch fabric (L3 Configuration).
- We can’t merge all VM behind a single DMZ (single segment for all VMs).
- Need to create new subnets for VMs.
+ Distributed routing for VMs.
+ Microsegmentation between VMs of the same DMZ.
+ We keep the same security zone, firewall rules on perimeter firewall don’t need to change.
+ Less hop than scenario 1 between BMS and VM.
+ Less hop than scenario 3 between BMS and OUT.
Scenario 3 : Service interface
In this scenario we are using NSXT service interface to manage everything into NSXT. The aim is to have a single interface for Firewall rules (The NSXT Manager).
- Firewall rules migration to gateway FW can be challenging.
- EdgeCluster is Active/Passive (no ECMP).
- Need more dedicated edge cluster to load shared traffic.
- More latency for BMS to exit the security zone than before move. (Edge + FW)
- Need to migrate the original DMZ to the edge cluster.
- Need to create new subnet for VMs.
- Possibility to create a single segment for all VMs. Not necessarily a good idea.
+ Perimeter firewall can be removed or kept for N/S traffic only.
+ The security zones stay in NSX. If the perimeter firewall is kept, a single interface is needed.
+ Full NSX => no L3 with underlay, same portal for firewall rules.
+ The traffic between BMS and VM has less latency than in scenario 2.
+ Less VRF than scenario 3.
Scenario 4 : Edge Bridge
- Not recommended because L2 is streched.
- Risks of instability.
- BMS to exit the DMZ need to go through at least two NSX Edges.
+ Can keep the same subnet between VM and BMS.
+ Can use microsegmentation between VMs.
Traffic consideration
The diagram below can highlight some traffic pattern to help understanding the challenges of some design scenarios. This is not an exhaustive diagram it only helps at the beginning of the design phase.
