hello World,
Me again trying to re-start the thing that matter the most to me and my blog posting is one of those, so It has been I while since the last post, but I will try not to bluffing and going directly to the action, many shi...things has happened and new things have filled my brain, so let's begin with a simple one: Microsegmentation (using NSX-V obviously), first at this point everyone knows what is about this, what does it mean, and what are the benefits, but going in deep there some points unclear at least form the deployment perspective or consultant perspective I mean by that when you had to have all the answers in front of final consumer of the NSX product.
Let's refer to this customer as ZZZ bank who has the requirement to protect the virtual environment with something that beloved sales team fellows have printed in his mind called microsegmentation, so in essence the ZZZ bank will be enabled to enforce L2-L4 firewall rules and L7 rules with 3 party vendor (Panorama form Palo Alto in this case) at vnic level, enforcement is the how but let's check what about microsegmentation.
First in my conception microsegmentation is the logic to the construction of how this enforcement is placed how the thing is going to be grouped and what rules and from there how what traffic is going to be redirected to 3party services is going to happen.
in practice you have to deploy NSX, then group the VMs in Security Groups then put them security tags to populate SG's and then create FW rules for L3 communications and steering for advance service analysis (packet processing), simple right?? well here is what is going to happen in this example ZZZ bank has a big challenge in define the application, that means they know a sh....nothing about what is the application and how is this connected with others and the intra and intercommunications and tiering and transactionality and so on so forth, so first challenge is going to be addressed by using vRealize Network Insight, presto right?? now we are going to define or check in some way how the VM's are communication each other, no so fast, remember ZZZ bank don't know WTF with this VM's so if you imagine for a moment a beautiful shine 3tier with DB, WEB, and APP as part of Application X, that is not the case, there is another challenge here VM's will be running the 3er itself just because, nothing else, then VRNI will help to define flows but your permutation for the FW rules will be a madness, so anyway what I want to share is the how to troubleshot or proof you innocense depending on your situation, we do the integration with 3party in this case Palo Alto, yes is another element of this guacamole, in top of a restricted by policy and human superpowers vSphere environment and complex definition of microsegmentation of applications ZZZ bank is looking for the power of inspection in East-West communication, in other words how those Applications are sending packets and what kind of protocols in the communications ports are using.
So for reference using this link to get in touch with this fancy integration between NSX and Palo Alto and uses cases also:
PD. don't forget the web server for the OVA of Palo Alto since I got a chide by one of my fellows in the past about that point but anyway just not sense discussion.
So let's assume this list has already taken place:
- vSphere is up and running
- VRNI is up and running (can be Log Insight which I prefer from cost and simplicity, and only for mapping flows)
- NSX v is up and running (no controllers)
- ST's configured and assigned
- SG's Created and populated
- the logic of microsegmentation already in place (analysis and definition of FW rules at L3)
- Panorama is u and Running
- The VM series are deployed in every ESXi host that is going to use the service
So you need to take the step of "integrate" Panorama and NSX, so for that check that the policy created from panorama is pushed to the NSX manager nothing special and is documented.
At this point you create a simple set of rules in partner security services section inside of NSX FW, the case of ZZZ bank involves a VM called hr-web-02 and the VM called hr-db-01, some explanation here, they are not in overlay or such a demoniac thing (from the physical networking guys quote and it is true) the 2 VMs are in dvPortgroups backend, they are in same network segment this to make more close the real customer environment example, nevertheless the results are the same if you where using VXLAN Logical Switches or if you want to reproduce using the HOL for Palo Alto integration which can give you more hands-on and not be taken as an absolutely true this post so check it here : http://bit.ly/VMware_HOLs_NSX_PA , so the VM of web ip address is 192.168.130.205 and VM of DB ip address is 192.168.130.203
Ok so here is the first point you need to be aware of: No matters if the VMs have NSX FW enforcement, a.k.a. there are FW rules for the VM's at NSX level for restricting or permit communication in presence of Network inspection service (redirect to PA) only if the traffic is not doped at NSX level this will be processed in the 3 party engine in this VM series local Service Virtual Machine in the ESXi host where the VM "lives", so this means for example if WEB VM has an NSX rule (among other rules of course) to permit communication towards a DB VM in port 1433 and then you have to set a redirect rule, for instance, port 3362 from same flow this is going to be steer and evaluated in the SVM according to the rules in Palo Alto (Palo Alto is going to "import" the SG's in Address Groups to create the rules at Panorama level.) otherwise if the traffic is not allowed on this port 3362 and you want to inspect the traffic on Panorama this traffic is not going to steer In summary the allow action in NSX FW rule permits the service insertion.
Second point to consider: sometimes is easy to follow the youtube examples and blog post about microsegmentation in 3tiers for everything using Service Composer, that is cool but remember in this example VMs contains 3tier in same VM so is not so easy to find a common denominator for all the permutations of rules of the firewall, so that will takes you to do it in a manual way, in other words, if this is the condition you can create the NSX redirect rules for traffic manually.
Third point to consider: there is a big difference undocumented (I did not find it anywhere) about the direction on traffic depending on what are you using for redirect the traffic in VMs, if you are using Service Composer the redirection is in taking place when the traffic gets in the destiny, the other option is when you set the redirection manually the steer if happening in the source, this may be sound something stupid but when you have to check when the infamous PUNT (label that indicated derivation of traffic to SVM or Palo Alto in this case at packet level or the formal definition “Send the packet to a service VM running on the same hypervisor of the current VM.”) is painted at logs level in the ESXi host in order to define if this is happening or not depending on where is VM involve is located.
Destination VM hr-db-01 ESXi esx-02a host
Source VM hr-web-02 ESXi esx-01a host
Final point to consider: Check where is the communication happening is easy to infer but where to show up where is really things happening you need to get int he logs, again from the GUI can see everything is ok but sometimes we are required to define more detail so for that don't get crazy looking in vmkernel.log or somewhere else just go directly an run this logs:
CLI commands for print logs
tail -f dfwpktlogs.log
in this case, since we are using a manual approach the redirection is happening in SVM where destination VM is located in this case the DB VM and clearly, you can see the magic of redirection in the logs level, you can run the command to check log in source and destination host as shown:
logs on the source host
logs on destination
and check as well in NSX manager using the following commands to print logs of static rules been enforced just to check the redirect one applied.
first, select the cluster where the VM is located on
then run the following command to check the ESXi host
locate the VM and run this command
when getting the VM to list the interfaces where Filter are applied in this case Firewall rules
Finally, check rules been applied to the instantiation of the services
Finally, check rules been applied to the instantiation of the services
in this case, we are exploring the DB VM and pay attention in the tag for the rule according to the GUI above (we ser vRay, the second check the ruleset number, in this case, is 652 the corresponds to the NetX API rule IDs
same case for the Web VM
so for second day operations you can save much time by leverage of VRLI since well configured (NSX content pack) is going to receive this kind of logs without the necessity to login in each ESXi host and run any sort of CLI commands, just be aware of the flags lingo for that check this link http://bit.ly/LOG_and_sysEvents_of_NSX.
So you can conclude that complexity depends on what customer, in this case, ZZZ banks wants to do from the business perspective, what sales teams just over the surface deal with the idea of customer and the solution and finally how in reality is going deeper and have the answers to simple questions or what if scenarios.
hope this help in any way to make your life less complicated.
c-ya
+vRay
