Monthly Archives: February 2012

Where’s my Static ? A basic example of the NAT model introduced in Cisco ASA 8.3

[“Most of the change we think we see in life is due to truths being in and out of favour“. – Robert Frost]

Yes… we know that. Adapting to change is frequently a challenge. If you invested time and effort to learn a certain way of getting stuff to work, it is not that easy to accept newer forms of accomplishing something similar (at least when you first see it).

Despite the reasons presented to justify the new Network Address Translation (NAT) model introduced by version 8.3 of the ASA software, many people will think (and say): “just bring back my static !” I understand that particular perspective but the key fact to be aware of is that getting familiar with the new philosophy is vital to enable your organization to migrate to 8.3 and beyond (and profit from the most recent feature developments…)

While the previous article, “NAT Evolution within Cisco ASA software“, covered the main differences between the three generations of the NAT functionality for ASA, the current post has a simpler objective: to present a basic example of Static NAT, with the two possibles syntaxes (pre and post-8.3). The topology and related commands to illustrate that are summarized in the figure below.

Implementing Static NAT on ASA: pre and post 8.3

If you look carefully at the output of  show nat command, you will be able to notice that the translation just configured generated a rule at Section 2 of the Unified NAT Table (an instance of the so called Auto NAT or Object NAT). Some relevant comments about this type of arrangement follow:

  • The real address is part of a network object definition. This object can be later employed in other sections of the configuration, such as in an Access Control Entry (ACE) or under an object-group definition.
  • The mapped address is created by using a nat statement as a parameter of the network object (previously used for the real address).
  • A given Object NAT rule can be employed to translate either the source or the destination address of a packet but not both at the same time. If you need to deal with more complex requirements (Policy NAT or Dual NAT, for instance), Twice NAT will be the adequate choice.

It is really advisable that you compare the old and modern ways of defining static NAT. It is also a good idea to start planning the conversion of the configurations in your specific environment. Future posts will illustrate more situations (dynamic PAT, Policy NAT and dual NAT are planned topics). Stay tuned !

** Topics for Study:

** Related Posts:


Filed under English, Firewalls, Security

NAT Evolution within Cisco ASA Software

[ “There is nothing permanent except change” – Heraclitus ]

Given that Network Address Translation (NAT) is a baseline functionality on most firewall implementations, it is really critical to understand NAT behavior (on your particular release) before you start configuring access control rules. To help you in this task, the current post briefly reviews how the NAT philosophy has changed through the history of Cisco Adaptive Security Algorithm (ASA) software.

  1. Before release 7.0 (PIX product line) the only available option was the “nat-control” model. When this model is in place, you are supposed to provide an explicit answer regarding the use of NAT (even when you do not want the firewall to perform address translation).
  2. From 7.0 to 8.2, the default operation mode is no nat-control, meaning that NAT  is not mandatory anymore. If the intention is to restore the pre-7.0 behavior, you can still issue the nat-control command.
  3. Starting on ASA 8.3 release the NAT model was completely redesigned. The most significant changes are listed below:
  • There is no concept of nat-control anymore. NAT is simply an optional feature.
  • 8.3 and newer releases employ a brand new NAT syntax.
  • NAT table is now divided in 03 sections, thus allowing a better control of NAT precedence rules. These 03 sections (and their main characteristics) are illustrated in the figure.
  • Dual NAT rules (those that translate both source and destination simultaneously) are now defined as a single statement.
  • When NAT is in place, Access Control Entries (ACEs) refer to the Real Address (as opposed to previous models which considered the translated address). This is a very important difference to be aware of before you migrate to 8.3 and beyond.

The Unified NAT table introduced by ASA 8.3

It is important to emphasize that if you are using a pre-8.3 ASA release, and need new features that were added on 8.3 (or later), you will need to understand the newest NAT model (and convert the rules accordingly). On the other hand, if you have a brand new appliance, it is advisable to start with 8.3 (or 8.4) so that you avoid migrating NAT rules later…

More posts on this topic, presenting practical configuration (and conversion) examples, will come soon. Stay tuned !

** Related Posts:


Filed under English, Firewalls, Security

IPv6 Migration: Host and Routing Functions on Cisco Catalyst Switches

IPv6 support is a hot topic today on any networking circle. Given the exhaustion of IPv4 addresses and the promisses of new services over IPv6, it is very natural for most customers to be concerned about buying products that already include v6 features or, at the very least, a sound roadmap. (Moreover, some industry segments have even defined regulations about IPv6 support on equipments to be acquired).

But, before you start selecting your IPv6-enabled devices, it is certainly advisable to understand the differences between the host and routing functions:

  • Host Functions: the ability to be inserted in an IPv6 network and managed using the classic protocols (over IPv6). For instance, ICMP, Telnet, Syslog, DNS. L2 devices such as the Catalyst 2960 (LAN Base) already include this type of functionality.
  • Routing Functions: the ability to route IPv6 packets. Support starts on the Catalyst 3560 series for Cisco L3 Switches (specifically in the IP Services feature set).

Given that Layer 2 Switching, in most environments,  is a suitable choice for the access layer,  you do not need to upgrade your entire base to L3 just to support v6. Deploying L2 (with IPv6 host functions) in the access layer, with IPv6 routing capabilities in the distribution and core layers, will typically guarantee a smooth transition to v6.

As a reference, a list of the IPv6 host features available in the Catalyst 2960 family (LAN Base image) is presented below:

  • Telnet and SSH for remote access to the CLI
  • HTTP and HTTPS for graphical management of the switches
  • DNS for name resolution over IPv6 (AAAA records)
  • TFTP for file transfer (OS images and configuration files)
  • SNMP and Syslog
  • ICMPv6 (including Ping and the Neighbor Discovery processes)
  • Stateless Autoconfiguration over IPv6
  • A small number of IPv6 Static Routes (to give you flexibility on reaching the switch from a management perspective). This is not intended to be used as an IPv6 router.

** Further Reading:

** Related Posts:

Leave a comment

Filed under English, IPv6, Routing

Quick Review of IP Routing

IP routing is concerned with the choice of a path over which the IP datagrams, destined to a given host, are sent. And it is important to emphasize the word destination here. Even though there may exist advanced techniques that rely on attributes such as the source address, the classic definition of routing considers the destination address as the sole criterion for path selection.

The main tasks pertaining to the routing process are listed in the following:

  1. Gathering routing information: either manually (static routing) or with the use of dynamic routing protocols.
  2. Installing entries in the routing table: before installing a path in the routing table, two comparisons are performed by a Cisco router: if two equal length network prefixes are available to a destination, the router prefers the one with the lowest Administrative Distance (AD). For two equal length prefixes that have the same AD value, that with the lowest cost (from the perspective of the routing protocol in place) is chosen.
  3. Searching for the longest prefix match: when a packet arrives at the incoming interface, its destination IP address is extracted and compared with each entry available in the routing table. The comparison that results in the longest bitwise match for the network mask will be selected. (The last possibility of finding a match is to use a Default Route, if one is available).
  4. Forwarding the packet on the outgoing interface: when a match happens in step 3, it points to an entry in the routing table that has an associated outgoing interface. This last step includes the construction of the appropriate L2 header for this interface.

To simplify matters, I normally divide the IP routing process in two parts: building the routing table (control plane) and using the table to forward packets (data plane).

The figure below depicts a scenario in which the host is using the routing services  provided by the “blue” router to forward packets to the destination with address After consulting its routing table, the router concludes that the intended host is reachable via its Ethernet1 interface (using R1 as the next-hop).

Overview of IP Routing

** Notes:

  • The simplest routing case happens when the incoming and outgoing interfaces are directly connected to the same router. In this type of situation steps 1 and 2 are not necessary.
  • When two routes to a given destination point to the same outgoing interface and have equalvalues for AD and cost, they are both installed in the routing table. In such a situation, load sharing takes place.

Leave a comment

Filed under English, Routing

How IOS IPv6 ACLs handle ICMPv6 Neighbor Discovery messages

Traditional IPv4 ACLs are typically written as a sequence of permit statements that include an implicit deny clause as their last line. Although this implicit deny is also present on IOS IPv6 ACLs, there are some additional facts to be aware of:

  1. There are other implicit (permit) statements designed to allow two of the main Neighbor Discovery (ND) messages:  permit icmp any any nd-na (which handles Neighbor Advertisement messages) and permit icmp any any nd-ns (which takes cares of Neighbor Solicitation messages).
  2. If your environment requires Router Advertisement (RA) and Router Solicitation (RS) messages to be allowed, these lines will need to be configured explicitily (in the same way as the regular permits).
  3. In the event you add an explicit deny as the last line of the V6 ACL, this statement will take precedence over the implicit permits earlier described (for nd-na and nd-ns).

Now that you are aware of these characteristics of IPv6 ACLs with regards to Neighbor Discovery, don’t forget to add the following lines before the explicit deny (“deny ipv6 any any“):

     permit icmp any any nd-na

     permit icmp any any nd-ns

     permit icmp any any router-advertisement

     permit icmp any any router-solicitation

After all, as seen on a previous article, ND messages are necessary for the correct operation of IPv6 networks…

** Related Posts:

IPv6 Series:

ACL Series:

Leave a comment

Filed under English, Firewalls, IPv6, Security

Some IPv6 link-local processes and the associated ICMPv6 messages

ICMPv6 goes beyond the traditional diagnostic and error reporting services delivered by its IPv4 counterpart. Some ICMPv6 are simply indispensable for a series of link-local processes related to Neighbor Discovery (ND). The main messages and some of the processes they apply to, are described below:

  • Router Adverstisements (RA messages): identified by ICMP type 134, are sent periodically or in response to a Router Solicitation message. An RA is sent to the All-Nodes multicast address with a link-local scope (FF02::1) and includes one or more network prefixes and possibly other data, such as the default router and the MTU on that link.
  • Router Solicitation (RS messages): generated by hosts at boot time to request immediate sent of RAs by routers, so that they do not need to wait for the periodic RA and can promptly start autoconfiguration. ICMP type 133 is associated with RS messages.

Figure 1: ICMv6 Router Advertisement (RA) and Router Solicitation (RS) messages

Two other important ICMPv6 ND messages, Neighbor Solicitation (NS) and Neighbor Advartisement (NA), respectively identified by types 135 and 136, are mainly employed in the following tasks:

  • Duplicate Address Detection (DAD): to avoid address conflicts on a link, a node invokes the DAD mechanism whenever a new address is configured. For example, if host H1 wishes to configure the unicast address X1, it sends an ICMPv6 Neighbor Solicitation to the solicited-node multicast address corresponding to X1. If any other host on the link responds, it means that the intended address is already taken and cannot be assigned.
  • Layer 2 Address Resolution (ARP Replacement): If host H1 wants to send a packet to H2 on a local-link, it first needs to determine the layer 2 address of H2. H1 accomplishes that by sending a NS message to the solicited-node address corresponding to H2. The data portion of the NS contains the Query “what is your L2 address? “. H2 then sends a Neighbor Advertisement message  to H1, revealing its Layer 2 address. The hosts can now communicate using IPv6 unicast addresses.

Figure 2: Layer 2 Address Resolution and Duplicate Address Detection for IPv6

Due to the role played by ICMPv6, the (almost automatic) procedure of blocking ICMP (typical of IPv4 networks) will need to be reconsidered. Otherwise the basic IPv6 link-local processes will fail…

** Topics for Study:

  • Play with the ping and the show ipv6 neighbor commands to examine L2 Address Resolution
  • It may be interesting to enable the debug ipv6 icmp and debug ipv6 nd commands on your lab to get more familiar with the main ND processes.
  • Are you able to apply Flexible Netflow (described in a previous post) to gain visibility of the ND messages ?

** Related Posts:

Leave a comment

Filed under English, IPv6

Gaining visibility of your IPv6 traffic with Flexible Netflow

Within the context of computer networks, a flow is defined as an unidirectional sequence of packets between two network endpoints, one of which acts as the source and the other as the destination. Historically, the seven key fields that have been used to univocally identify an IPv4 flow are:

  • Source IP Address
  • Destination IP Address
  • Layer 3 Protocol Type
  • Source Port Number
  • Destination Port Number
  • Type of Service (ToS)
  • Input Logical Interface

Netflow is a powerful functionality that was designed to raise awareness about the utilization of network resources. The flow distribution data obtained by means of Netflow may be applied to domains such as capacity planning, network application monitoring, accounting and security analysis.

Although Netflow was originally defined for IPv4, it is also available for IPv6 and, as such, it becomes an interesting resource for gaining more visibility about the traffic flowing through your v6 network.

Figure 1 revisits, as a quick reference, the base IPv6 header. The motivation for inserting it here is to make your life easier on understanding the Netflow fields that will be analyzed later.

Figure 1: Base IPv6 Header

Flexible Netflow is an evolution that allows us to elect the fields that should be part of the flow record, meaning that we are not limited to a set of predefined fields anymore. The set of fields selected may provide a different perspective about a given group of packets crossing the L3 device. For instance, certain fields may be useful for capacity planning while a distinct combination could be more meaningful for security tasks such as spotting Denial of Service (DoS) attempts.

A sample configuration of Flexible Netflow for IPv6 is summarized in Figure 2 to facilitate the understanding of the basic concepts:

  • We established the fields that comprise the flow record. The match statements identify the key fields, whereas collect statements determine the non-key fields. (It is a good exercise to compare the IPv6 base header fields with those shown in Figure 2).
  •  If two packets differ in at least two of the key-fields they are not part of the same flow.
  • The flow export entity defines the way in which flow data will be exported (destination IP, destination port and source interface). Notice that v6 flow information is still exported using IPv4.
  • The flow monitor structure ties the flow record and flow export settings and is later bound to an interface (either in the ingress or egress direction).
  • Figure 2 also exemplifies a possible view of the flow monitor cache.

Figure 2: Sample configuration of Flexible Netflow for an IPv6 environment


** Related Posts:

Leave a comment

Filed under English, IPv6

Cisco IOS Zone-based Policy Firewall: L7 inspection for FTP over IPv6

In a previous post we examined the main usages of L7 inspection on a stateful firewall (IPv4 perspective):

  1. Fixing up misbehaved protocols, such as those that dynamically negotiate data connections inside the control channel. Classic examples are FTP and the telephony signaling protocols (SIP, H.323 framework, SCCP, MGCP).
  2. Perform Network Address Translation (NAT) at the application level for those protocols that embed the IP address in the L7 messages. This is critical within NAT and Port Address Translation (PAT) environments.
  3. Use the application knowledge to filter based on additional criteria pertaining to the specific L7 protocol, rather than just L4/L3.

On another article of the IPv6 series, we analyzed a basic L4 inspection policy for a v6 environment. Now we will apply the Cisco Zone-based Policy Firewall (ZFW) L7 awareness to a simple FTP scenario built upon IPv6. But, before we jump to the example itself, there are some relevant facts to highlight :

  • Current support for IPv6 in the ZFW covers case 1 of the main usages of L7 inspection listed before.
  • If you need to fixup an application protocol that is running over non-standard ports, you can leverage the ipv6 port-map command (pretty much in the same fashion we employed  the ip port-map command before).
  • The application knowledge is not used for filtering purposes yet.

The figure below depicts not only the ZFW policy structure but also the audit-trail logs for the FTP session (both the control and thedynamically  negotiated data channels). Notice that the match protocol statement uses the ftp keyword, which instructs the ZFW to use its understanding of the FTP application to handle this session. (It is not generic TCP !)

Sample Zone-based Policy Firewall scenario for FTP over IPv6 inspection

** Topics for Study:

  • What are the FTP over IPv6 commands that correspond, respectively, to the PORT and PASV commands ?
  • Examine the output of the show ipv6 port-map command
  • Play with the appropriate show commands for this setup. Good starting points are show zone security and show policy-firewall config zone-pair.

** Related Posts:

Leave a comment

Filed under English, Firewalls, IPv6, Security

Sample Configuration of the Cisco IOS Zone-based Policy Firewall with IPv6

Now that we have studied several practical scenarios for the Cisco IOS Zone-based Policy Firewall (ZFW), it is time to apply this knowledge to IPv6 environments. It is very important to emphasize that the logic of policy construction (as well as the building blocks) are identical to those employed for IPv4.
Our reference topology brings a simple network containing two security zones and an L4-only policy that defines the rules to allow the initiation of  outbound connections. The figure also documents the output of a typical debug command used to gain visibility about session creation.

Basic Zone-based Firewall configuration for IPv6

** Topics for Study:

  • By reviewing the contents of previous posts in the ZFW series, would you be able to insert L3 restrictions in this scenario ? (For example, the client host in the INSIDE should only be able to access FTP and HTTP on the OUTSIDE server).
  • How can you enable logging ? (both for connection setup/teardown and dropped packets)
  • What are the commands used to display information about existent security zones and structure of policy elements ?

** Related Posts:

Leave a comment

Filed under English, Firewalls, IPv6, Security

Introduction to IOS IPv6 ACLs

This post quickly discusses simple Cisco IOS IPv6 Access Control Lists (ACLs). As summarized in the figure, the construction logic of the ACL is basically identical to the classic v4 ACLs (those that do not use object-groups). The permit (or deny) statements are created by specifying the following elements (in this order):

  • source of the traffic
  • destination of the traffic
  • services involved (from source to destination)

One noticeable difference refers to the way in which v6 ACLs are applied to interfaces: the correct command to accomplish that task is the ipv6 traffic -filter (and not something such as “ipv6 access-group”).

Basic Description of simple IOS IPv6 ACLs

** Notes:

  • Object-groups for v6 elements are not supported on IOS yet.
  • IOS supports IPv6 ACLs that allow filtering based on the v6 extension headers.

** Related Posts:

Leave a comment

Filed under English, Firewalls, IPv6, Security