The Distributed Firewall dashboards are definitely my favorite feature of vRLI. You can see the total number of firewall actions triggered, the top rule that is hit, audit events, top sources, top destinations, ports allowed or denied, and more. With all of this data, it’s possible to use vRLI to start creating your DFW rules because you will be able to see what VMs are communicating over specific ports. Near the end of this post, I will write a brief tutorial on how you can use the filter logic to determine DFW rules that need to be put in place.
The one downside to using vRLI to get this data, is that you must first enable logging on the rules for which you would like to display information; it makes sense after all since vRLI gathers this information via (you guessed it) logging. The problem is that if you want visibility into your traffic, you will be logging a lot of information and it can eat up a lot of resources if it is logging a ton of traffic events. As a side note, my next posts will be focusing on vRealize Network Insight which is a much more powerful tool to use for traffic discovery, DFW rule creation, and a holistic view of your network; Stay tuned because I love this new product!
Let’s get started! To enable logging for your rule(s) you will navigate to the DFW, and add the log field and save the configuration. I have a default rule that is allowing all traffic to pass (I know not best practice) but it will show me all the traffic in my environment.
Once you enabled the logging for the rules, go to the Distributed Firewall Overview dashboard. You will see five different DFW dashboards, I will cover most of the data here, or at least what I feel is most important.
Distributed Firewall Overview
The DFW Overview tab is a good place to see what traffic is being passed, or better yet, what traffic is being dropped. Dropped traffic isn’t necessarily a bad thing, it can mean your firewall is doing what it is intended to do and keeping out malicious activity. Using this dashboard, you can filter the firewall actions to specify only passed, or only dropped traffic by clicking on the corresponding link on the right. I will filter out all passed traffic so that only dropped traffic is displayed. From there, you can click on the bar graph, and go to the interactive analytics to determine the IPs, ports, and protocols of the dropped traffic.
As you can see, the traffic being dropped is from IP 172.16.10.50 to IP 172.16.10.7 over proto1 (ICMP) by rule 1005. Using this, you can determine if something is being appropriately dropped, or if a firewall rule needs to be changed to allow the traffic.
On the flip side, if I filter by allowed traffic, you can see 172.16.10.100 is communicating with 172.16.10.7 over UDP 514 and the allowed traffic is being passed by rule 1001.
Top Rule Hit Count
Top rule hit count is also useful to know what firewall rule is being processed the most. You can use this to determine if there needs to be changes to the rule, or if it expected behavior based on the type of workload or application.
vRLI can also be used to audit changes to the DFW. I quickly created a rule, modified it, then saved the DFW configuration. If you navigate to the Distributed Firewall Overview dashboard you can see the most recent audit events. If needed, you can change the dashboard (or any dashboards) to display the last 5 minutes, hour, 24 hours, or a custom time range. It’s also possible to click on any of bar graphs, or audit events to review more information on the log entry.
Distributed Firewall Alerts
I don’t have too much to cover in this section, but I wanted to put a screenshot out there for everyone regardless as it can be useful in troubleshooting scenarios. I haven’t seen many issues with the DFW since working with NSX, but if there are any errors with spoofguard, filter config, service profile, missed flows, dataplane, or daemon changes, this is probably the first place to check to determine what the log messages say. I have provided an example of some log entries below, where the DFW daemon was either stopped, started, or restarted on the ESXi host.
Distributed firewall Traffic
The Distributed Firewall – Traffic is definitely my favorite dashboard in vRLI with NSX. Not only because it looks pretty, but also because it can be very useful in helping to create firewall rules, I’ll explain more in the last section, but first let’s take a look at what information is displayed.
Top Firewall Sources and Destinations
While the top firewall sources and destinations are limited to 25 results, it is still very helpful to review where the majority of the traffic is passing through the firewall based on the source or destination IP address. As with any of the other dashboards, you can click any of the IP address in the right to filter through the pie chart. You can also pick a section of the chart, based on what IP is relevant, and go to the interactive view to see more information about the top sources and destinations like what rule is passing this traffic and what port or protocol is being used.
Once you are in the interactive analytics view, you view this information. The filter logic in this situation is all passed traffic by the firewall, where the source IP address is 172.16.10.7. It’s very easy to modify this filter logic and create your own logic to help you troubleshoot, create firewall rules, update firewall rules, and more.
Applications Ports permitted or Denied
Taking it one step further, you can also see the top applications ports that are being passed. Nothing is being dropped at this time, because
I am being a bad admin I haven’t created my firewall rules yet.
Top Sources and Destinations by bytes
How to create Firewall rules for DFW by using VRLI
If we were to put this all together, we should be able to use vRLI to help determine what DFW rules that we need to create in both a greenfield and a brownfield deployment. There are several ways you can accomplish this task, but if it were my environment, I would run through the following tasks.
- Set the default DFW rule to allow all
- Make a list of applications that are running in your environment, as well as their IP addresses
- Use filter logic to through each VM and or application to determine what ports the VMs are communicating over
- Determine valid traffic, and create an allow rule in the DFW section
- The default rule should have a lot less traffic hitting it at this point, use VRLI to determine if there is any outstanding traffic that needs to have an allow rule
- Set default DFW rule to deny all
Any new applications that need to be implemented, can have new DFW rules added, this will typically only be used for existing rules or a new DFW deployment where rules need to be determined. Hopefully everyone finds this useful and sees the power of using the vRLI content pack with NSX. As always feel free to comment if there is anything else you would like to see, or if there are any other cool features that you have found in the vRLI NSX content pack.