VMware Networking Community
Floki00
Enthusiast
Enthusiast

NSX DFW Firewall Rules - How to

Hi Guys,

I am currently working to implement a lockdown of internal resources using the DFW. Currently most of the rules do not work properly, and I am unable to troubleshoot properly using the Traceflow tool, due to the source being external to the platform (Cannot reference a vNIC, PortGroup, DPOrtGroup, etc).

My question is this, is it possible to block traffic from a whole subnet i.e can I have a rule like:

Rule Block 192 to 191: User Firewall

Source 192.168.192.0/24 destination 192.168.191.0/24 service *any Allow Applied to Distributed Firewall

Default Rule: Block All

Please how can I block whole subnets as currently this is not working. I am still confused how the DFW works, any pointers will be greatly appreciated.

Kind regards,

Floki

Reply
0 Kudos
16 Replies
rajeevsrikant
Expert
Expert

Source 192.168.192.0/24 destination 192.168.191.0/24

- Which is the segment internal to NSX & which is external.

Assuming 192.168.192.0/24 - Internal & 192.168.191.0/24 - External.

You need to set 2 IP Sets

IPset 1 - Internal_Segment: 192.168.192.0/24

IPset 2 - External_Segment 192.168.191.0/24

You can define the policy as below

Source: Internal_segment -> Destination: External_Segment -> Service: Any -> Action Allow/Deny => Applied To <Distributed Firewall or Logical switch>

you can apply the DFW rule to Distributed firewall or to the logical switch which is associated with the Internal_Segment network.

Reply
0 Kudos
tanurkov
Enthusiast
Enthusiast

HI

please use IPset and define your networks there and then you can block any kind of external traffic in NSX.

do define IPsets you need to go to NSX manager tab in vSphere and objects , IPset and you can configure them. please exclude yourself and VC from the IPset . because you can block your self if you management cluster is prepared for NSX.

Regards Dmitri

Reply
0 Kudos
rajeevsrikant
Expert
Expert

The most important think which needs to be considered for the DFW is the applied to settings.

Below link explains the importance of it. Kindly go through it for more clarity.

The importance of NSX Distributed Firewall "Applied To" setting - Eat Sleep Virtualize Repeat

Reply
0 Kudos
Floki00
Enthusiast
Enthusiast

Hello All,

Thanks for the information provided, very much appreciated.

@rajeevsrikant I have noticed something, since we have a layer 3 switch and performing inter-vlan routing on the switch, it seems as a result of this routing on the physical network, some of the traffic do not traverse the virtual layer as I cannot see all the traffic hitting the DFW (i.e when I check the dfwpktlogs.log file, I cannot find the traffic being "PASS" or "DROP").

Have you come across this scenario anywhere?

Thanks,

Floki.

Reply
0 Kudos
tanurkov
Enthusiast
Enthusiast

HI

Please log the activity that you trying to trace.

i.e create a rule for what you need and just after the rule put log for any any .

then open dfwpktlogs.log and search for the activity

Regards Dmitri

Reply
0 Kudos
Floki00
Enthusiast
Enthusiast

Hello Dmitri,

Thanks for your reply, very much appreciated. I have logging turned on for all the rules for testing purposes, some traffic is being allowed without it being logged hence why I assumed this must be because that traffic had already being routed before hitting the DFW.

I may be wrong!

Thanks,

Floki

Reply
0 Kudos
rajeevsrikant
Expert
Expert

Just wanted to clarify your point.

You mean to say even you have applied the DFW policies for the VMs , the policies are not being enforced.

If the above is true, could you please share the details of the Applied TO field.

In NSX DFW, if any rule is applied to any VMs it can not bypass the firewall policy.

By default it is going to check the traffic entering & leaving the vNIC, of the VM. If the policy matches it takes the required action, if the policy does not matches it skips the rule & checks the next rule.

Reply
0 Kudos
tanurkov
Enthusiast
Enthusiast

HI Floki

Do you apply rules base on VM object or by source and destination, even if traffic is already routed you should able to see hits on DFW if the rules are applied correctly. You can make for the test propose a more general rule with source and destination with no ports.

Please let me know we can take a look on it together if needed.

Regards Dmitri

Reply
0 Kudos
Floki00
Enthusiast
Enthusiast

Hello rajeevsrikant,

The rules are being applied to the "Distributed Firewall" .

Thanks,

Floki

Reply
0 Kudos
Floki00
Enthusiast
Enthusiast

Hi Dmitri,

I have tried rules using the IP address and also the source and destination subnets. I am having less luck with the subnets using IPSETS.

Thanks,

Floki.

Reply
0 Kudos
tanurkov
Enthusiast
Enthusiast

HI Floki00

then is really interesting , it would be hard to troubleshoot in the dark !

try to capture with this command

pktcap-uw --capture PreDVFilter --dvfilter nic-zzzzvvv-ethx-vmware-sfw,2 --srcip 1.1.1.1

See is there any traffic , just change IP and nic name

Regards Dmitri

Reply
0 Kudos
farhan_p2000
VMware Employee
VMware Employee

Hi,

As I understand you need to implement a block rule.

Could you share the following:

a. Network topology

b. Is there a default allow all rule?

Hence you want to implement a block rule before it?

Regards,

Farhan.

Reply
0 Kudos
Floki00
Enthusiast
Enthusiast

Hi All,

It seems I'm right on this one, as you cannot use DFW for non-virtual workloads, please see below tests.

http://www.vrandom.com/nsx/firewall/vmk/

The tests show DFW can only block traffic from within the NSX environment. This is what I am also experiencing. You can block external traffic to a VM in your NSX environment, but not block traffic to a vmkernel for example and other limitations if the routing has occurred outside NSX environment.

Thanks,

Floki

Reply
0 Kudos
bayupw
Leadership
Leadership

Hi Floki, just want to highlight the questions that being asked in the previous replies.

You mentioned that your DFW rule as follows:

Source 192.168.192.0/24 destination 192.168.191.0/24 service *any Allow Applied to Distributed Firewall

I assume the source and destination are IPSets objects in NSX.

But is there any VM objects in these two subnets or are they non-virtualised workloads?

As you mentioned, you cannot use DFW for non-virtual workloads as DFW runs in the ESXi hypervisor or on VM's vNIC.

If either source or destination is a virtual workload, you can still use DFW such as in the following cases:

  • Physical to Virtual
  • Virtual to Physical
  • and Virtual to Virtual

VMKernel is not counted as virtual so that would be physical

If you want to have firewall on ESXi VMKernel, it would be the ESXi Firewall

Just an additional note, NSX virtual machines are also excluded from DFW see this doc Exclude Virtual Machines from Firewall Protection

Bayu Wibowo | VCIX6-DCV/NV
Author of VMware NSX Cookbook http://bit.ly/NSXCookbook
https://github.com/bayupw/PowerNSX-Scripts
https://nz.linkedin.com/in/bayupw | twitter @bayupw
Reply
0 Kudos
Floki00
Enthusiast
Enthusiast

Hello Bayu Wibowo,

Yes, the 2 subnets referred to are not strictly virtual workloads, they are a mix of virtual and physical resources. Also just as you mentioned

"

If either source or destination is a virtual workloads, you can still use DFW such as in the following cases:

  • Physical to Virtual
  • Virtual to Physical
  • and Virtual to Virtual

VMKernel is not counted as virtual so that would be physical

"

I have physical workloads connected to the same VLAN subnets as my VMware Virtual Machines (VMs). I have noticed the Firewall rules referencing the subnets did not work for the traffic originating from the physical going to something like the VMKernel interfaces, thus Physical to Physical as you pointed out this type of traffic cannot be handled by NSX.

Thanks,

Floki.

Reply
0 Kudos
tanurkov
Enthusiast
Enthusiast

HI Floki00,

DFW is not acting on VMkernel interfaces. NSX DFW is actin with in the NSX domain and vmkernel is not a part of it.

to use physical to to virtual you need to use any/or IPset as a source  to destination which is virtual workflow

Regards Dmitri

Reply
0 Kudos