Cisco ASA vs. Palo Alto: Management Goodies

You often have comparisons of both firewalls concerning security components. Of course, a firewall must block attacks, scan for viruses, build VPNs, etc. However, in this post, I am discussing the advantages and disadvantages from both vendors concerning the management options: How to add and rename objects. How to update a device. How to find log entries. Etc.

Cisco ASA

  • Fast Management Suite: The ASDM GUI is really fast. You do not have to wait for the next window if you click on a certain button. It simply appears directly. On the Palo, each entry to add, e.g., an application inside a security rule, takes a few seconds.
  • Better “Preview CLI Commands”: I am always checking the CLI commands before I send them to the firewall. On the Cisco ASA, they are quite easy to understand. I know, Palo Alto also offers the “Preview Changes”, but it takes a bit more time to recognize all XML paths.
  • Better CLI Commands at all: For Cisco admins, it is very easy to parse a “show run” and to paste some commands into another device. This is not that easy on a Palo Alto firewall. First, you must change the config-output format, and second, you cannot simply paste many lines into another device, since the ordering of these lines is NOT correct by default. That is, it simply doesn’t work.
  • ACL Hit Count: I like the hit counts per access list entry in the GUI. It quickly reveals which entries are used very often and which ones are never used. On the Palo, you can only highlight the never used ones. Furthermore, the CLI on the ASA splits each ACL into the real objects with individual counters. Great!
  • VPN Session Monitoring: For a quick glance, the VPN session monitor is great to see all phase 1 and phase 2 security associations incl the TX/RX packet counts.
  • Many SNMP OIDs: There are many options to monitor the ASA via SNMP. On the Palo Alto, e.g., you can not monitor sub-interfaces. This is really bad. Only the bare metal ethernet ports reveal counters.

Palo Alto PA

  • Out-of-Band Management Interface: Even the smallest PA-200 device has its own management interface with its own routing table (default route). This makes it easier to permit/deny admin accesses to this host. E.g., there is no confusion between an access to the SSL VPN and an access to the management GUI since they reside on different interfaces and IP addresses.
  • Browser-based GUI: No Java, no client. Just a simple browser. It is also manageable through SSL VPN portals.
  • In-Band Interface Management Profiles: On the ASA, every access through different interfaces and different protocols needs its own line to be configured (Management Access -> ASDM/HTTPS/Telnet/SSH). Management access is denied per default, while ping is allowed by default. Both must be set in different menus. Not on the Palo: Interface Mgmt with a few clicks and optional IP addresses, configurable on several interfaces.
  • –> Single Security Policy: All interfaces AND site-to-site VPNs are in zones. All security policies between these zones are in one security policy. On the ASA, you don’t have the ACLs for the VPNs in the ACL view of the interfaces since you must specify extra ACLs to the group policy of the VPN.
  • Zone Based Security Policies: A policy from zone A to zone B only takes effect for this pair of zones. The “incoming interface” policies on the ASA always have a destination of “any” zone. Though the destination addresses can be limited, it is more complicate to configure the policies if there are several interfaces in use (and not only inside and outside).
  • Network Objects in Slash-Notation: Add a host or a network object by typing “”. On the ASA, you have three fields for the same object: host or network, IP address of the network, and netmask (in 255.x.x.x notation!) for the network.
  • Tags: A simple but useful feature are the coloured tags that can be used in policies and objects. With these tags, temporary policies or the like can easily be marked.
  • –> Managing all Un-Commited Changes: One of the best features! Configuration changes can be done in any menu of the Palo Alto, showing the candidate config in all other menus right now, even without a commit. If you rename an object here, it is visible with this new name there. (Try to change the IP-address and the default gateway on a remote Cisco ASA firewall by one step. You won’t succeed until you are using the CLI.)
  • Simple Renaming of almost Everything: (Except subinterfaces) Address objects, address groups, zones, security profiles, IPsec tunnels – everything can be renamed. Try to rename an IPsec connection profile on the ASA. Or an interface name. It won’t work or you will get tons of CLI changes.
  • History of Configuration Changes: Ever tried to revert to the config from last day? No problem: Load configuration version.
  • Configuration Log: Ever wondered who changed something? Here it is: Monitor -> Logs -> Configuration. An exact list of all configuration changes with the name of the administrator.
  • Config Audit: Comparison of two configurations, such as of the running-config and any other historical config on the device. Great feature to find certain configuration changes.
  • –> Traffic Log Filtering: This is one of the MAJOR advantages of a Palo Alto GUI. It is really simple to click some objects to filter the traffic log. Or to build more precise filters. “eq” and “neq” are your friends. ;) Forget the Real-Time Log Viewer from Cisco.
  • Adjust Columns: Or even the possibility to adjust the columns. On the ASDM GUI from Cisco, some pages are per default to small to show the relevant values, e.g., the Monitoring -> Routing -> Routes pane.
  • Application Command Center: A simple but useful monitoring tool within the GUI. You are searching for the IP that generates high traffic load during the last hour? Here you will find it. What source country is responsible for the attacks during the last week? Here you go.
  • –> Route-Based VPN: A site-to-site VPN connection is built by two gateways, independent of the traffic being routed through the tunnel. Numbered tunnel-interfaces can be used to ping the tunnel endpoint of the other side. The decision where to route the traffic is based on the routing table and not on a policy. The Cisco firewall uses policy-based VPNs in which the Proxy-IDs per connection define the tunneled networks. A bit unhandy.
  • –> IKE Policy per VPN: Every gateway has its own IKE profile configured. Different IKE settings can be used for different VPNs. The Cisco has global IKE parameters.
  • Own Zones for VPNs: Site-to-Site VPNs can be in extra zones. On the ASA, VPNs are always associated with the “outside” interface, which is complicated for using NAT policies.
  • Reasonable Default Crypto Settings: The default groups for the IPsec phase 1 and phase 2 crypto profiles have almost secure settings. Very good compared to the Cisco ASA, which really installs a view default profiles, e.g., an IKE policy with an encryption algorithm of “DES”. Yes, not 3DES, but only simple DES! Oh oh.
  • Retrieve License Keys from Server: Really cool feature. And very easy to use for the customer. Once the authorization code is added in the Palo Alto support portal, the firewall can retrieve its license via https. No need for any further activation keys.
  • Built-In Software Archive: Firmware versions can be downloaded directly through the GUI. No need for further logins, downloads from the vendor page and uploads to the unit. Just “Download” and “Install”.
  • Enough Disk Space for several Softwares: On my (small) Cisco ASA 5505, the built-in flash disk has only 128 MB. That is, I cannot even do a simple software upgrade because the free disk space does not fit for two ASA images. (I have an ASA and ASDM image as well as three AnyConnect images on the fash memory.) What a mess!
  • Sync Software to HA Member: Every software that is downloaded on the primary firewall can automatically be synced to the secondary device. This is not true on the Cisco ASA, which is really annoying when it comes to AnyConnect remote access VPN client images. If these are not uploaded manually on the second device, the other HA unit will not terminate VPN tunnels in case of a HA active-unit swap. Oh oh!
  • HA Status in GUI: With the High Availability widget, the status of the HA is visualized with green/orange/red bubbles. It shows which unit is the active/standby one. Since the PA has a real OoB management, the admin can access both devices simultaneously and can see which hardware is the active and the passive one. The Cisco ASA swaps its IP addresses and has no OoB management, so it is harder to see which hardware is the primary and the secondary one, since its IP addresses swap, too.
  • NTP Servers with Names: I know that NTP servers should be set via IP addresses to not rely on another service (DNS), but it is much more easier to use names such as or the like. This can be done on the Palo Alto, but not on the Cisco firewall.
  • No “bring to top” GUI: During the start of Cisco’s ASDM, it always brings its GUI to the top of all windows. In my opinion, this is annoying. During the 30-60 seconds until the whole device config is loaded into the GUI, I am working on other things. But these are generally disrupted from the highlighting of the ASDM GUI. This does not happen with the Palo Alto GUI which is in one tab of my browser.

(The major advantages are marked with an –> arrow.)


In summary, I really love the management GUI from the Palo Alto. Not hard due to the list of more than 20 advantages over the Cisco ASA platform. ;) Though it is slower than the ASDM GUI from Cisco, it offers much more useful capabilities for daily work. Great!

© Image Sketch by Mareike Weber.

14 thoughts on “Cisco ASA vs. Palo Alto: Management Goodies

  1. Looks like you are working for PA :-)
    I don’t think you had set up proper test cases and did not include/explore all benefits of ASA. I worked with both ASA and PA and both have advantages and disadvantages but comparing them as you did here is not valuable and very partial.

    1. Hi Mike,
      I am working with both firewalls. And in my opinion, the PA is better to manage.
      If you have any more advantages for the Cisco ASA, please tell me! :)

      1. This comparison is missing some of the great components in terms of management, visibility, security, and intelligence features.

        1. You should compare ASA + FirePower Services

        2. out of band management interface – Adaptive Security Device Manager (ASDM) V 7.3.X is available to provide on-device, access control and advanced threat defense management. ASDM V 7.3.X provides an enhanced user interface that provides quick views on trends and the ability to drill-down for further analysis.

        3. FireSight for Enterprise. You can centrally manage Cisco ASA with FirePOWER Services with the Cisco FireSIGHT Management Center. Gain comprehensive visibility into users, mobile devices, client-side apps, virtual machine (VM)-to-VM communications, vulnerabilities, threats, and URLs. Also, gain control over activity within the network and across next-generation firewall (NGFW) deployments.

        4. Advanced Malware Detection – Discovery and protection against advanced malware and threats

        5. Identity Service Engine – Get a security policy management platform that automates and enforces context-aware security access to network resources. Cisco Identity Services Engine delivers superior user and device visibility to support enterprise mobility experiences and to control access. It shares data with integrated partner solutions to accelerate their capabilities to identify, mitigate, and remediate threats.

        6. Cisco Talos – It is important to compare the Security Intelligent when we select security product. Cisco Talso creates threat intelligence for Cisco products in order to detect, analyze, and protect customers from both known and emerging threats.

        1. The comparison should focus on Security Management rather than device management.

      1. Danke!

        Da ich nur mit Palo Alto arbeite war mir der Vergleich ehrlich gesagt nicht so wichtig. Die Vorzüge sind mir aber durchaus bekannt :-)

  2. I disagree with the author of this article. Gui on PA firewall is very slow. Commiting even tiny changes are even slower.

  3. It always nice to see folks giving their time and energy in reviewing products. I do have some input on what I have found working in CISCO ASA. See Below

    Out-of-Band Management Interface: Cisco – No true out of band you would need an external out of band manager that you are using for the rest of your gear.

    Browser-based GUI: Cisco – Java is a bummer but not a deployment killer. After you, VPN in you can manage via ASDM if you want.

    In-Band Interface Management Profiles: Cisco – I think this give you better control, very few people should have access via a few interfaces.

    Single Security Policy: I have worked with PA, and you have to set a new policy for every network you want to connect to. On a Cisco ASA, you simply do an OBJ and then control access via the ACL. You can do an ACL in the VPN if you want.

    Zone-Based Security Policies: PA if you 20 networks you need twenty policies and if these networks need to talk to 10 on the other side that 200 policies. Cisco you just set up the OBJ and control via ACL. So much cleaner and faster.

    Network Objects in Slash-Notation: I do not see this as a big deal some might.

    Tags: That would be nice to have

    Managing all Un-Committed Changes: Cisco – No you can make as many changes as you want then click apply. You will see the CLI lines that will be changed before they are deployed so you can double check your work. I may be missing your point.

    Simple Renaming of almost Everything: This would be a nice to have. OBJ in the ASA cannot be renamed way to go PA.

    Configuration Log: We Use Opmanager device expert for more than just who did what. You can set up AAA logging in the ASA then sent the logs to a log server so you have all your devices activates in one place. Cisco router have had this feature for years and I do not remember when I have ever used it.

    Traffic Log Filtering: Cisco – This is super easy in a Cisco ASA.

    Adjust Columns: Cisco Most columns are adjustable

    Application Command Center: Cisco has had this since the Pix days. It is on the main dashboard of the ASDM, or you can do it via CLI.

    Route-Based VPN: You can do route base with a router and encrypt the traffic via the ASA. There are other ways to make traffic selection if needed when the base IPSec does not suit your needs. NO GRE yet….

    IKE Policy per VPN: Cisco – True on the IKE, but you can add or delete any protocol you want, and you can granularly control IPSEC for every tunnel.

    Own Zones for VPNs: Not true, you can enable any interface to be a part of VPN. Nat’s are not complicated and have gotten easier in the 8.3 code. They are more like checkpoint now.

    Reasonable Default Crypto Settings: You can be deleted them at any time.

    Retrieve License Keys from Server: Units are shipped with the key in them. Only if you change or add a special feature such as mobility after the initial purchased you will need a new key.

    Built-In Software Archive: You can download code right from the ASDM with your CCO account and save it to flash.

    Enough Disk Space for several Software’s: A 5505 is for a SOHO office other enterprise models are a lot larger. The new 5500x has plenty of room and horsepower. ASA with firepower (IPS, Malware and URL) runs great even when are under attack from what we have seen.

    Sync Software to HA Member: Very true and it is annoying you do need to load the IOS, Certs, ASDM, and packages into flash on the secondary one. An extra 15 min of work.

    HA Status in GUI: You can see the HA status in the ASDM. However, it is not a green, yellow, red bubble.

    NTP Servers with Names: Cisco ASA- Since 8.3 code you can use FQDN for any firewall rule set.

    No “bring to top” GUI: The GUI load fast not sure if you are testing and old 5505.

Leave a Reply

Your email address will not be published. Required fields are marked *