VMware Networking Community
Shamyy
Enthusiast
Enthusiast

Direction option when creating firewall rule

Hello Community ,

please need your help as i want to know what is the use of Direction option ( highlighted in yellow ) , as i changed it but i don't notice any change

fw direction.PNG

Thanks ,

Shamy

20 Replies
bayupw
Leadership
Leadership

This blog post explains when "direction" option matter https://nealdolson.com/2017/01/09/vmware-nsx-distributed-firewall-rules-scoping-and-direction-matter...

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
Shamyy
Enthusiast
Enthusiast

thanks Bayu ,

but unfortunately i don't understand how we use it !

Reply
0 Kudos
ndolsontts
Contributor
Contributor

What don't you understand?  That blog post was mine, btw. 

As an example scenario:

1)  a DFW rule is created for "web servers" that says source "any" to destination "web server" over 80/443 is allowed and the direction is set to in/out

2)  you have an app server where the only traffic allowed outbound is source "app server" to destination "database server" over 1433 and the direction is set to in/out

3)  all other traffic not explicitly allowed is blocked by the default rule

In this scenario, even though the firewall rules applying to the application server only allow communication over 1433 to the database server, the "any" 80/443 rule applied to the web servers counts as a policy match for the app server, as it is indeed part of "any" possible source.  By having the direction set to "in/out" and scope as "any", it's basically implying that not only do you want to allow 80/443 in to that web server, you also want all the other VM's in your NSX domain to be able to send outbound traffic from them to the web server over 80/443.  Even if you'd replaced the source of "any" with something broadly scoped like an IP range, you might still run into a scenario where traffic that you didn't intend to allow is effectively allowed anyway.

Let's modify the above scenario:

1)  a DFW rule is created for "web servers" that says source "any" to destination "web server" over 80/443 is allowed and the direction is set to in

2)  you have an app server where the only traffic allowed outbound is source "app server" to destination "database server" over 1433 and the direction is set to out

3)  all other traffic not explicitly allowed is blocked by the default rule

In this scenario, you should see that 80/443 traffic is still allowed inbound to the web server, but your application server is not able to access the web server as it could previously. 

I haven't been able to find much documentation on VMware's site or in the admin guides regarding "direction".  What I could find was mainly related to north/south firewalling on the ESG, and in this scenario VMware stated they did not recommend modifying the "direction" field.

In my opinion, the way that the "direction" column is hidden in the DFW by default, and the way that traffic is implied and allowed when a direction of in/out is set, is counter intuitive. 

Reply
0 Kudos
Shamyy
Enthusiast
Enthusiast

thanks ndolsontts ,

good job btw

what i don't understand is when we change the direction for first rule to "in" , and the direction for second rule to "out"

why app server cant access the web server as it could previously ALTHOUGH the first rule has source "ANY" it include app server too

and why we need a direction as i know when i create rule from source to destination so the direction will be "in" in destination servers and "out" in source servers.

Thanks,

Shamy

Reply
0 Kudos
ndolsontts
Contributor
Contributor

source = "any" destination = "web server" protocol = "HTTP" direction "In/Out":

     We have a DFW policy match for the app server thanks to the "any" source.  With direction "In/Out" it seems to imply that we want to also allow outbound HTTP on any system that gets a policy match...which will be "everything" under the NSX domain, again, due to the "any" source.  Even though in a different ruleset section where we are only allowing 1433 "out" of the app server to a backend database server, the policy match from the "web server" ruleset combined with a direction of "In/Out" allows HTTP traffic out of the app server to the web server.

source = "any" destination = "web server" protocol = "HTTP" direction "In"

     We have a DFW policy match for the app server thanks to the "any" source (you can confirm this is still considered a policy hit by using the "filter" option in the DFW even though the HTTP traffic won't pass from app to web).  With direction "In" it allows HTTP in from "any" source to the web server, assuming that the source has the ability to send HTTP traffic to the web server. Without the direction set to "In/Out" on the policy applying to the web server, the app server no longer has the ability to send HTTP traffic to it.

When you allow the HTTP traffic into the web server, the web server can still reply HTTP back to the source system without needing an explicit firewall rule allowing such (stateful).

I don't really know any other way to put it, but hopefully that helps.  The direction thing is confusing to me as well in that it did not behave how I expected it to...my background is not in firewalls so I don't have a ton of experience outside of the fundamentals of their operation to draw upon, prior to NSX.  It'd be easy, especially in a multitenant environment, to allow an app server in "tenant b" to hit the web server in "tenant a" over HTTP because of "any" and "In/Out" applying to the web server, unless a blacklist rule between tenants was also present (i.e. source = "tenant a" destination = "tenant b" protocol = "*" direction = "In/Out").

It's also important to note that if you're creating firewall rules using Service Composer, I could not find a way to modify the direction and therefore it uses the default value of "In/Out".

Reply
0 Kudos
rajeevsrikant
Expert
Expert

In simple terms can we assume it as below.

If "IN" option is selected - Any traffic on the ingress (incoming traffic in the vNIC) the policy is checked.

If "OUT" option is selected - Any traffic on the egress (outgoing traffic in the vNIC) the policy is checked.

If "IN/OUT" option is selected - Both ingress & egress (incoming & outgoing traffic in the vNIC) the policy is checked.

Let me know if the above understanding is right.

Reply
0 Kudos
iforbes
Hot Shot
Hot Shot

Would a best practice (to avoid all this in/out confusion) be to use explicit Source/Destination objects, and not *any? If you use explicit Source/Destination you could leave the Direction as in/out.

Reply
0 Kudos
ndolsontts
Contributor
Contributor

That's the ideal scenario, but sometimes it's just not possible to do an explicit VM-to-VM rule.  Sometimes you'll have to, at a minimum, specify a range of subnets when you have no control over what the source or destination may be.  "Direction" appeared to be a "work around" of sorts to this as mentioned earlier, though if you'd filter your firewall rules it's still be a policy match and considered for processing.

However, there were some enhancements made to the "apply to" options in the DFW which actually seem to work now.  Example - previously in 6.2.x and below, when using Service Composer, you could specify a Security Group to "apply to", but all it really seemed to do was manipulate which security group was in the source or destination fields in the Security Policy's firewall rules - the direction could only be "In/Out" (as far as I was ever able to find), so broadly scoped sources or destinations could still cause unintended consequences.  Additionally, while in Service Composer you may have specified a Security Group to "apply to", when viewed in the DFW section, it still showed "applied to" of "Distributed Firewall".  Now in 6.3, in the DFW itself, you can modify the "apply to" field, and select a granular object for which the rule applies to.  Instead of "applies to" being "distributed firewall" and presumably applicable to all, you could say "applies to > web tier security group" and only entities contained within that security group apply the policy.  In summary, once I specified an "apply to" of "web tier security group" in my web tier firewall rule, the "any" source to destination "web tier security group" over "http" no longer allows "http" from any of my other VM's, even when the direction is set to "In/Out".

I've nearly completed testing this in my lab and will try to put it into a more concise blog post.

Reply
0 Kudos
ndolsontts
Contributor
Contributor

I confirmed in my lab environment that using, for example, a Security Group or an individual VM, in the "Applied To" field of the Distributed Firewall rule does restrict the application of that firewall rule to just the object specified.  i.e., I still have a source of "any" for inbound HTTP on my web server, that rule is configured to "apply to" the Security Group containing my web server, and other VM's in the 3 tier app (or entirely unrelated for that matter) no longer have the ability to hit the web server over HTTP unless explicitly allowed otherwise.  I created a quick blog post detailing my testing and the configuration changes that were made.  http://nealdolson.com/2017/02/16/vmware-nsx-v-6-3-improved-distributed-firewall-scoping-options

This was a very welcome change/feature for me in NSX 6.3.  Direction can still be used where it makes sense, though it doesn't have to be to limit the flow of traffic as it'd been used as a work around previously.

Reply
0 Kudos
rajeevsrikant
Expert
Expert

Thanks.

Sorry still i have a query.

From your blog I understood that you have set the rule as below

Source - ANY    Destination -  Web Servers    Port - HTTP   Action - Allow  Applied  to - Security group which contains your web server.

I am not able to understand how "DB" server  is not matching the source as "ANY" & allowing the access.

This part i am not clear.

Reply
0 Kudos
ndolsontts
Contributor
Contributor

Because that rule does not apply to an object that contains the database server.  The rule as you stated allows HTTP traffic inbound to the web server from "any" source, which also assumes that the source has the ability to send it HTTP traffic.  The database server has no rule applying to it that allows it to send HTTP traffic to the web server.  If I created a new rule that said source = database server, destination = web server (or some object containing the web server), protocol = HTTP, and applied to = database server (or some object containing the database server), then it'd have the ability to.  Otherwise, the default deny rule is applicable.

Reply
0 Kudos
rajeevsrikant
Expert
Expert

Thanks.

So this enhancement is only available in 6.3 & not available in 6.2.x

Reply
0 Kudos
bayupw
Leadership
Leadership

If you are referring to "Applied To" option it is actually available in NSX 6.2 as per documentation

In the Service Composer, yes the default behavior is Applied To Distributed Firewall but this can be edited in the Service Composer menu as per documentation here:

VMware NSX for vSphere 6.2 Documentation Center-Edit Service Composer Firewall Applied To Setting

service-composer-policySG.png

This is also required when you have vRA-NSX and would like to do Micro-segmentation with vRA to allow overlapping IP and App Isolation.

On NSX 6.1 an API call through vRO was required.

Similar on the DFW Menu, we can change the Applied To field to specific objects prior NSX 6.3

VMware NSX for vSphere 6.2 Documentation Center-Add a Firewall Rule

The enhancements on NSX 6.3 as per blog post NSX-V 6.3: Cross-VC NSX Security Enhancements - The Network Virtualization Blog is around for Cross-VC objects.

Prior NSX 6.3, Universal DFW can only use "Applied To" on Universal Logical Switch.

Since there there is a new object in NSX 6.3 - the Universal Security Group we can now Applied To the Universal Security Group

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
rajeevsrikant
Expert
Expert

Thanks bayupw‌ for the detailed explanation.

In my environment with NSX version 6.2.2 I have the below rule. (Not configured via Service Composer)

Source - ANY    Destination - Web Server Security Group(5 VMs)    Port - HTTP   Action - Allow  Applied  to - Web Server Security Group

Default next policy is Deny ALL

So in this scenario you mean to say that if I try to do HTTP from a VM in APP Server Security Group http will be blocked.

Reply
0 Kudos
DaleCoghlan
VMware Employee
VMware Employee

Technically "Applied To" for DFW has been available since 6.0.x.

And like Bayu has said, "Applied To" for Service Composer was made publicly available in the UI in 6.2.x, but previous to that, was done via an un-documented API, or by running the vRO workflow "Enable security policy support for overlapping subnets".

Dale

Reply
0 Kudos
rajeevsrikant
Expert
Expert

Thanks.

I tested the below scenario & it is working as expected.

Source - ANY    Destination - Web Server Security Group(5 VMs)    Port - HTTP   Action - Allow  Applied  to - Web Server Security Group

Default next policy is Deny ALL

Tried  HTTP from a VM in APP Server Security Group & it was blocking.

Checked the firewall rules in the APP server using Central CLI & found that the server didn`t receive the firewall rules.

Changed the apply to rule to `Distributed Firewall` & checked the rules for APP server. This time the firewall rules was available in the APP server.

Reply
0 Kudos
hansroeder
Enthusiast
Enthusiast

This is indeed as expected. You apply the rules to the Web Server Security Group and nothing else. So the firewall on the hosts will indeed only apply this rule to the IP addresses that are behind this group of VMs. What if you create the same rule again (I would replace "Any" with the APP server) and then apply this to the APP server? Or use "Applied To" to apply the rules in the one rule you already have to both Web and App. In my opinion this should work, since the rules will then also be applied to the IP addresses that are behind the APP server object.

Reply
0 Kudos
rajeevsrikant
Expert
Expert

Yeah thanks.

Reply
0 Kudos
Mparayil
Enthusiast
Enthusiast

Hello Shamyy,

I saw this post as Not answered so thought of answering this, Please find the below details

Let me first tell you when to use unidirectional rule IN/OUT

From NSX DFW stand point you can USE IN or OUT only when your SOURCE or DESTINATION is out of NSX DFW firewall boundary

for Example : ANY to WEB "in this case ANY can be physical or Virtual but No enforcement point since it is ANY" so when you configure your rule as IN to Web server the HTTP connection is allowed.

pastedImage_1.png

Let me know if I was able to clear your query