1 2 Previous Next 20 Replies Latest reply on Oct 6, 2018 11:23 AM by priscillagr

    Direction option when creating firewall rule

    Shamyy Novice

      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

        • 1. Re: Direction option when creating firewall rule
          Bayu Wibowo Master
          User ModeratorsCommunity Warriors
          Bayu Wibowo | vExpert NSX, VCIX6-DCV/NV, Cisco Champion, AWS-SAA
          Author of VMware NSX Cookbook http://bit.ly/NSXCookbook
          https://nz.linkedin.com/in/bayupw | twitter @bayupw
          • 2. Re: Direction option when creating firewall rule
            Shamyy Novice

            thanks Bayu ,

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

            • 3. Re: Direction option when creating firewall rule
              ndolsontts Novice

              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. 

              • 4. Re: Direction option when creating firewall rule
                Shamyy Novice

                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

                • 5. Re: Direction option when creating firewall rule
                  ndolsontts Novice

                  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".

                  • 6. Re: Direction option when creating firewall rule
                    rajeevsrikant Expert
                    Community WarriorsvExpert

                    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.

                    • 7. Re: Direction option when creating firewall rule
                      iforbes 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.

                      • 8. Re: Direction option when creating firewall rule
                        ndolsontts Novice

                        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.

                        • 9. Re: Direction option when creating firewall rule
                          ndolsontts Novice

                          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.

                          • 10. Re: Direction option when creating firewall rule
                            rajeevsrikant Expert
                            vExpertCommunity Warriors

                            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.

                            • 11. Re: Direction option when creating firewall rule
                              ndolsontts Novice

                              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.

                              • 12. Re: Direction option when creating firewall rule
                                rajeevsrikant Expert
                                Community WarriorsvExpert

                                Thanks.

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

                                • 13. Re: Direction option when creating firewall rule
                                  Bayu Wibowo Master
                                  User ModeratorsCommunity Warriors

                                  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 | vExpert NSX, VCIX6-DCV/NV, Cisco Champion, AWS-SAA
                                  Author of VMware NSX Cookbook http://bit.ly/NSXCookbook
                                  https://nz.linkedin.com/in/bayupw | twitter @bayupw
                                  • 14. Re: Direction option when creating firewall rule
                                    rajeevsrikant Expert
                                    vExpertCommunity Warriors

                                    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.

                                    1 2 Previous Next