We’re excited to introduce our Network Insight™ for Palo Alto firewalls! This is the fourth Network Insight feature, and we’re building these in direct response to your feedback about the most popularly deployed devices and the most common operational tasks you manage.
Network Insight features are designed to give you tools specific to the more complex and expensive special-purpose devices in your network infrastructure. While the bulk of your network consists of routing and switching devices, the more specialized equipment at the edge requires monitoring and visibility beyond the standard SNMP modeled metrics we’re all familiar with.
So, what kinds of visibility are we talking about for Palo Alto firewalls?
The Palo Alto firewall is zone-based, with security policies that describe the allowed or denied connectivity between zones. So, we’ll show you how we capture and present those security policies. We’ll show you how we can help you visualize application traffic conversations between zones, to help you understand how policy changes can affect your clients. Another critical feature of the Palo Alto firewall is to secure communications between sites, and to provide secure remote access to clients. We’ll show you how to see your site-to-site VPN tunnels, and to manage GlobalProtect client connections.
Palo Alto firewalls live and die on the effectiveness of their security policies to control how they handle network traffic. Policies ensure business processes remain unaffected and perform optimally, but unintentional or poorly implemented policies can cause widespread network disruption. It’s critical for administrators to monitor not only the performance of the firewall, but the effect and accuracy of the policy configuration as well. As these policies are living entities, continually being modified and adjusted as network needs evolve, the impact and context of a change may be missed and difficult to recover. This is why in Network Insight for Palo Alto, Network Configuration Manager (NCM) brings some powerful features to overcome these pitfalls.
Once the Palo Alto config is downloaded and parsed, the policy information will populate the Policies List View page. This page is intended to make it easier to search through and identify the right security policy from a potentially long list, using configurable filtering and searching. The list view provides each policy’s name, action, zones, and last change. Once the correct policy is identified, users can drill down into each one to see the composition and performance of each policy.
The policy details page summarizes the most critical information and simplifies the workflow to understand if a policy is configured and working as intended. You can review the basic policy details, as well as the policy configuration snippet and review the object groups composed into the policy. Admins will be able to quickly analyze if additional action is required to resolve an issue or optimize the given policy.
Some policies are meant to extend across multiple firewalls and without a view to see this, it’s easy to lose context about the effectiveness of your policy. Network insight for Palo Alto analyzes the configuration of each firewall to identify common security policies and display their status. As an administrator, this lets you confirm if your policies are being correctly applied across the network and to take action if they’re not. If there’s a desire to provide more continuous monitoring of a policy standard, you can also leverage a policy configuration snippet as a baseline for all Palo Alto nodes.
With any configuration monitoring and management, it’s critically important to be able to provide some proof of compliance for your firewall’s configuration. With Network Insight, you can track and see the history of changes to a policy and provide tangible evidence of events that have occurred. Of course, this also supports the ability to immediately run a diff of the configs where this change took place, by simply clicking the “View diff” button.
How do you monitor your VPN tunnels today? We asked you guys this question a lot as we started to design this feature. The most common response was you’d ping something on the other end of the tunnel. That approach has a number of challenges. The device terminating the VPN tunnel rarely has an IP address included in the VPN tunnel’s interesting traffic that you can ping. You have to ping something past the VPN tunnel device, usually some server. Sometimes the company at the other end of the tunnel intentionally has strict security and doesn’t allow ping. If they do allow ping, you have to ask them to tell you what to ping. If that thing goes down, monitoring says the tunnel is down, but the device might be down, not the tunnel. All this adds work. It’s all manual, and companies can have hundreds, thousands, or more VPN tunnels. Worst of all, it doesn’t work very well. It’s just up/down status. When a tunnel is down, why is it down? How do you troubleshoot it? When a tunnel is up, how much traffic is it using? When’s the last time it went well?
This is a tough position to be in. VPN tunnels may be virtual, but today they’re used constantly as infrastructure connections and may be more important than some of your physical WAN connections. They’re commonly used to connect branch offices to each other, to HQ, or to data centers. They’re the most popular way to connect one company to another, or from your company to an IaaS provider like Amazon AWS or Microsoft Azure. VPN tunnels are critical and deserve better monitoring.
Once you enable Network Insight for Palo Alto, Network Performance Monitor (NPM) will automatically and continually discover VPN tunnels. A site-to-site VPN subview provides details on every tunnel.
There are a couple things going on here that may not be immediately obvious but are interesting—at least for network nerds like me.
All tunnels display the source and destination IP. If the destination IP is on a device we’re monitoring, like another Palo Alto firewall or an ASA, we’ll link that IP to that node in NPM. That’s why 192.168.100.10 is a blue hyperlink in the screenshot. If you’ve given the tunnel a name on the Palo Alto firewall, we’ll use that name as the primary way we identify the tunnel in the UI.
There’s different information for VPN tunnels that are up and VPN tunnels that are down. If the tunnel is down, you’ll see the date and time it went down. You’ll also, in most cases, see whether the VPN tunnel failed negotiation in phase 1 or phase 2. This is the first piece of data you need to start isolating the problem, and it’s displayed right in monitoring. If the tunnel is up, you’ll see the date and time it came up and the algorithms protecting your traffic, including privacy/encryption and hashing/authenticity.
The thing I’m most excited about is in the last two columns. BANDWIDTH! Since VPN tunnel traffic is all encrypted, getting bandwidth usage is a pain. Using a flow tool like NTA, you can find the bandwidth if you know both peer IPs and are exporting flow post encryption. It takes some manual work, and you can only see traffic quantities because of the encryption. You can’t tell what endpoints or applications are talking. If you export flow prior to encryption, you can see what endpoints are talking, but you have to construct a big filter to match interesting traffic, and then you have no guarantee that traffic makes it through the VPN tunnel. The traffic has the additional overhead of encapsulation added, so pre-encryption isn’t a good way to understand bandwidth usage on the WAN either. The worst part is that VPN tunnels transit your WAN—one of the most expensive monthly bills IT shops have.
Network Insight for Palo Alto monitors bandwidth of each tunnel. All the data is normalized, so you can report on it for capacity, alert on it to react quickly when a tunnel goes down, and inspect it in all the advanced visualization tools of the Orion® Platform–including the PerfStack™ dashboard.
Why does it always have to be the CEO or some other executive who has problems with the VPN client on their laptop? When I was a network engineer, I hated troubleshooting client VPN. You have so little data available to you. It’s very easy to look utterly incompetent when someone comes to you and tells you their VPN service isn’t working, and when it’s the CEO, that’s not good. Network Insight for Palo Alto monitors GlobalProtect client VPN and keeps a record of every user session.
This makes it easy to spot the most common problems. If you see the same user failing to connect over and over, but other users are successful, you know it’s something on that client’s end and would probably check if login credentials are right. “No, I’m sure you didn’t forget your password. Sometimes the system forgets. Let’s reset your password because that often fixes it.” If lots of people can’t connect, you may check for problems on the Palo Alto firewall and the connection to the authentication resource.
In this release, NetFlow Traffic Analyzer (NTA) is contributing to our latest Network Insight through an integration with Network Configuration Manager. NCM users who manage Palo Alto firewalls will see top traffic conversations by security policy on the NCM Policy Details page. Examining traffic by policy helps answer the question, "Who might be affected as I make changes to my security policies?"
Let's look at how we find this view. We'll start at the Node Details page for this firewall.
We'll use the slide-out menu in this view to select "Policies." This will take us to a list view of all the policies configured for zones on this device.
Selecting a policy from this list brings us to the Policy Details page.
Policies define security controls between zones configured on the firewall. For a Palo Alto firewall, a zone can include one or more interfaces. In this view, we're looking at all the conversations based on applications defined in the policy. It's a very different way of looking at conversations; this isn't a view of all traffic through a node or interface. Rather, it's a view related to the policy definition—so the endpoints in these conversations are running over the applications your security rules are based on. The mechanism here is filtering; we’re looking at application traffic that references the application IDs in your security policy. The endpoints in those conversations may be from any zone where you’re using this policy.
For an administrator considering changes at the policy level, this is a valuable tool to understand how those rules apply immediately to production services and what kinds of impacts changes to them will have. For this feature, you'll need both NCM and NTA. NTA, of course, requires NPM. NCM provides the configuration information, including the policy definition and the applications definitions. NTA reads application IDs from the flow records we receive from the Palo Alto Firewall, and correlates those with the policy configuration to generate this view. With NTA, of course, you can also easily navigate to more conventional node or interface views of the traffic traversing the firewall, and we integrate traffic information seamlessly into the Node Details page in NPM as well.
For most devices supported by User Device Tracker (UDT), all that's necessary are the SNMP credentials. We’ll pick up information about devices attached to ports from the information modeled in SNMP. But for some devices—the Cisco Nexus 5K, 7K, and 9K series switches, or the Palo Alto firewall—a set of command-line interface (CLI) credentials are required. We’ll log in to the box periodically to pick up the attached devices.
To support device tracking on these devices, you’ll need to supply a command line login. You can configure devices in bulk or individually in the Port Management section of the User Device Tracker settings page. Select "Manage Ports" to see the list of what devices can be configured.
Select one or more of these devices, edit their properties, and you'll find a section for configuring SNMP polling.
You’ll also find a section for configuring command-line polling. For devices requiring CLI access for device tracking—currently the Nexus switches and the Palo Alto firewall—you should enable CLI polling, and configure and test credentials here.
Be sure to enable Layer 3 polling for this device in the UDT Node Properties section as well.
You’ll see attached devices for these ports in the Node Details page, in the Port Details resource.
To see all the features of Network Insight for Palo Alto, you’ll want to have several modules installed and working together.
You can demo these products individually, or install or upgrade from any installer available in your Customer Portal.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.