Cisco ASA vs. Palo Alto: Management Goodies

Cisco ASA vs. Palo Alto: Management Goodies

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 “1.2.3.0/24”. 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 asde.pool.ntp.org 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.)

Share on FacebookPlus on Google+

SUBSCRIBE MORE CONTENTS