Third-party Firewall redirection via DFW

[VMwareCTO]

Hi folks, as a NSX new learner still building blocks I want to tell something and you will correct me if I am wrong, imagine any simple topology Compute-Cluster and a Edge/Mgmt Cluster where our NSX Edge is deployed and also a  single Palo Alto Firewall VM is also deployed.

Now consider that I need to apply a certain policy on VM-1 that run inside esxi-1 ( Applying that policy by the Palo Alto ): So to do that I will configre my DFW to catch the traffic based on what I want to apply or.. and tell my DFW to redirect that traffic to the Palo Alto VM that runs inside another Cluster to apply the policy on that traffic and let it do on its way.

Is what I said true? or the Palo Alto firewall policies is also distributed into all my ESXi hosts?

Many  thanks to you in Advance

[Sree]

Your understanding is correct regarding traffic redirection.  To add few more points -> Traffic steering is done at the hypervisor layer and we can leverage a NSX logical switch or a normal VLAN backed portgroup . Below diagram depicts the IO chain in the hypervisor layer. Assuming a VM is connected to logical switch , traffic(Outgoing) goes via these slots(a kind of virtual hop :smileyhappy: )  and Slot 4-12 is for third party services, so when we have a redirection rule , packet goes all the way from slot 0 to slot-4  and it will redirect the traffic to respective partner appliance and vice-versa for incoming traffic to the VM as long as rules are applied properly.

Please check -> https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/products/nsx/nsx-palo-alto-networks-white-p… 

[VMwareCTO]

Many thanks to you my friends I just read the NSX integration W/ Palo Alto NGFW white paper and the model design according to them is that a PA-VM is deployed into each ESXi-Host which is good, so anyways I know the blocks which is what you have written as your answers   (1).

And the another concept I know is that as below

Captured it from a VMworld session as the screen implies vsfwd connected directly to the NSX Manager to get the rules programmed into the vSIP kernel module what as we can consider in the physical world as the line card module right ? (2)

as we can see here we have  vNIC-FW and vNIC as much as I understand is that the FW policy is attached at the vNIC lvl which is Awesome (3)

Referencing 1,2,3. Please tell what is right and what is wrong so I make sure that I managed to understand the concept behind it : ) and many thanks in advance again 

[Sree]

VSIP is a kernel module which keeps receiving firewall rules from NSX manager and will push to VM's based on the rules.  Slot-2 is were firewall rules are stored which will have a rule table and a connection table(Active Connections) and irrespective of the VM movement these two tables will follow the VM and session state is maintained.  If you are still not clear, i will provide you with few sample rules and respective output from hypervisor.

[VMwareCTO]

You made it more clearer, However if you provide outputs from the hypervisor will enforce that concept more and more

[Sree]

In this scenario , we have a Virtual Machine - VM-A sending ICMP packets to its gateway 172.16.1.82 and we have a drop rule for the same for the destination IP 172.16.2.204 which is the first rule.

1. summarize-dvfilter output from hypervisor.

world 4010344 vmm0:VM-A vcUuid:'50 14 b0 21 53 67 26 a3-2b ba bd e8 12 b3 b9 42'

port 50331658 VM-A.eth0

  vNic slot 2

  name: nic-4010344-eth0-vmware-sfw.2

agentName: vmware-sfw

   state: IOChain Attached

   vmState: Detached

   failurePolicy: failClosed

   slowPathID: none

   filter source: Dynamic Filter Creation

  vNic slot 1

  name: nic-4010344-eth0-dvfilter-generic-vmware-swsec.1

agentName: dvfilter-generic-vmware-swsec

   state: IOChain Attached

   vmState: Detached

   failurePolicy: failClosed

   slowPathID: none

   filter source: Alternate Opaque Channel

As you can see from above output - rule is applied at Slot-2 of IO chain with failclosed policy (no traffic will route through the module until the failure is corrected.)

2) vsipioctl getrules -f nic-4010344-eth0-vmware-sfw.2

Using vsipioctl (Remember VSIP is the module which recieves the rule and push to the underlying VM -> vm-A for we have the L3/L2 rules in the below rule section.

ruleset domain-c7 {

  # Filter rules

  rule 1005 at 1 inout protocol any from addrset ip-vm-123 to ip 172.16.2.204 drop with log; ( VM-123 is the MOB ID for VM-A)

  rule 1003 at 2 inout protocol ipv6-icmp icmptype 135 from any to any accept;

  rule 1003 at 3 inout protocol ipv6-icmp icmptype 136 from any to any accept;

  rule 1002 at 4 inout protocol udp from any to any port 67 accept;

  rule 1002 at 5 inout protocol udp from any to any port 68 accept;

  rule 1001 at 6 inout protocol any from any to any accept;

}

ruleset domain-c7_L2 {

  # Filter rules

  rule 1004 at 1 inout ethertype any from any to any accept;

}

3. vsipioctl getflows -f nic-4010344-eth0-vmware-sfw.2

Count retrieved from kernel active(L3,L4)=1, active(L2)+inactive(L3,L4)=0, drop(L2,L3,L4)=0

851f1da70000000b Active icmp 0800 OUT 1001 0 0  172.16.1.81 -> 172.16.1.82 8 0 61068 61068 727 727

In the above output VM-A 172.16.1.81 is sending a ICMP packet to gateway 172.16.1.82  and it is captured.