Today we launched our newest product, Athena PathFinder!  The phenomenal growth in adoption of our main product, Athena FirePAC, gave us excellent insight around the needs for additional solutions.  Last year, firewall engineers we worked with zeroed in on two primary types of requests:

1. Extending Athena’s range of analytics that go deep into individual devices.  With even more limited time and resources, firewall engineers are in need of easier ways to make the analytics more actionable and supportive of certain operational realities.

With the releases of Rule Tracker, Object Standardization, Configuration Debugger and major advancements to our Change Impact functionality, FirePAC meets the requirements for interactive intelligence that is especially useful to security operations groups.

2. Extending Athena’s policy awareness from a device-specific to a network-specific perspective.  Macro level issues involving service availability across multiple devices, reachability based on routing, and what devices to touch to implement a change request are all extremely well-suited for Athena’s offline analysis.

With the release of Athena PathFinder, we stuck to our product development philosophy of offering tools that are focused and easy to use, yet powerful enough to save man years of manual effort.  This is our solution for firewall engineers who are seeking a handy way to test network behavior for troubleshooting and simplifying rule changes, and we made sure they can get started immediately with a free 2-week evaluation offer.

When something goes wrong in a firewall, finding the problem can be difficult.  Manual review of a configuration or analyzing traffic flow is tedious, frustrating, and error-prone.  In particular, NAT rules can trip the unwary, as evidenced by the frequent posts on NAT problems in the Cisco Users forum. For Cisco users NAT can be specified in a multiplicity of ways, and the Cisco documentation is not always a model of clarity. Due to the complexity of the configuration or the complex interplay of NAT rules, not being able to clearly understand the effect of NAT on packet flow can result in unanticipated access or denial of legitimate access to the network.

Let’s take a look at a real-life example of NAT confusion that we found in the Cisco support forums.  Although it is a simple example in terms of NAT semantics, the user found its analysis difficult and confusing enough to post it.  In his example, the author has a simple three-port PIX firewall, with the inside interface bound to 10.1.10.2 and the DMZ interface bound to 192.168.1.2.  He wanted all packets from inside going to the DMZ to be NAT’ed to 192.168.1.254.  So a global NAT rule was inserted.  Below is a fragment of the ACL rules the configuration that frames the discussion.  The complete configuration can be viewed here.

access-list dmz permit tcp host 192.168.1.1 host 10.1.10.1
access-list dmz permit udp host 192.168.1.1 host 10.1.10.1
access-list dmz permit tcp object-group db_svrs 10.1.10.0 255.255.255.0 eq 118
access-list dmz permit udp object-group db_svrs 10.1.10.0 255.255.255.0 eq 118
access-list NO_NAT permit ip host 10.1.10.1 host 192.168.1.1
access-list inside permit tcp host 10.1.10.1 host 192.168.1.1 eq smtp

Here are the NAT rules of interest.

global (dmz) 1 192.168.1.254
nat (inside) 0 access-list NO_NAT
nat (inside) 1 0.0.0.0 0.0.0.0
static (inside,dmz) 10.1.10.0 10.1.10.0 netmask 255.255.255.0

By examining the traffic flow data, the poster found that in fact no packets were being source-NAT’ed to 192.168.1.254.  The question is: why?

Using the Configuration Debugger tool in Athena FirePAC, it becomes very easy to determine the answer.  The Debug tool allows you to trace the flow of sets of packets through a firewall and determine precisely the ACL rules, NAT rules, and routes acting on each packet.   We’ll issue a debug query using the following parameters:

src=10.1.10.0/24, dst=192.168.1.0/24, svc=TCP

The Debug query result shows us that only two ACLs and the implied deny are involved in filtering these packets.  Here are the two ACL rules:

46 access-list inside permit tcp host 10.1.10.1 host 192.168.1.1 eq smtp
47 access-list inside permit tcp any any object-group web_svcs

The completed set of permitted packets that match these rules are identified by the Debug tool and shown in the following table.

As identified in this table, the NAT rules that apply here are shown below.

45: access-list NO_NAT permit ip host 10.1.10.1 host 192.168.1.1
64: nat (inside) 0 access-list NO_NAT
66 static (inside,dmz) 10.1.10.0 10.1.10.0 netmask 255.255.255.0 0 0

The Debug tool identifies the effect of these NAT rules, as shown in the following table.

Through this result, we see that any packets coming from the 10.1.10.0/24 network are being source NAT’ed to have the same source addresses as the original, although it happens because of different rules.  We also see that the NAT/global rule added to transform the source addresses of the packets originating from the inside interface do not have any effect because of the precedence in which the different types of NAT rules are applied in the Cisco PIX firewall.

The fix is relatively straight-forward.  The static rule at line 66 should be removed.  Once gone, the NAT/global rule will have the proper effect and all packets originating from the 10.1.10.0/24 network will be properly source NAT’ed, with the exception of packets with a source of 10.1.10.1, which will not be NAT’ed because of the NAT exemption rule at line 64.

As we have seen, the FirePAC Configuration Debugger is a very powerful tool for figuring out what’s going on inside a firewall configuration. It will identify the exact packets that are allowed for entire ranges of source and destination addresses and services and it will identify the specific rules that act upon each packet. The analysis is performed completely offline and does not require any data to be put on the network.  The solution is available now for all Cisco Security Appliances, Juniper Netscreen firewalls, and Check Point FW-1.

Today we announced the release of a cool new Athena FirePAC solution focused on debugging configurations for enterprise firewalls.  The Firewall Configuration Debugger allows you to troubleshoot service availability problems in an offline mode, using FirePAC’s traffic flow query capabilities.  The advantage of offline analysis is that it does not require you to enable logging or to inject test packets into your network to understand your firewall’s behavior.  When a service disruption occurs, and a quick answer is required to rule out the firewall as the cause or to isolate an actual problem in the rules, the Debugger is a fast, thorough and convenient way to get the job done.

The Debugger allows you to specify individual packets or entire subnets as source and destination addresses and the services to test.  It performs a reachability analysis using the routing rules and address translations to automatically determine the ingress or egress access lists or zone to zone policies, and evaluates how they act on the user’s input.  This traffic flow analysis makes it easy to troubleshoot rules as well as the packets that they allow or deny, so answers can be found in minutes, rather than hours when using ad-hoc testing.  When trying to identify what changes in the configuration may be responsible for the service availability problem, the Debugger can compare two versions and link each rule and object change to its impact on added or deleted traffic flows.  With the introduction of the Debugger, Athena applies its advanced analytics, that traditionally served the audit market and project-based requirements, and provides a tool that is highly useful to operations groups.

For more detailed information, watch my video about the Debugger.  Or request an evaluation from our excellent sales team.