Category Archives: Firewalls

Configuring Dynamic Policy PAT on ASA: current and legacy models

This post builds upon the previous discussions on the ASA NAT series to exemplify yet another category of address translation: Dynamic Policy PAT. In this type of scenario, a set of source addresses get mapped into a single global address when they need to reach specific destinations.

In our reference topology, those dmz stations belonging to the 10.10.10.128/27 subnet are port address translated to 172.16.16.125/32 when the destination is the out host 172.16.16.200. For different out hosts, the source IPs are not translated. Some important points to highlight:

  • It is important to observe that we are not translating the destination address. We are just using the destination criteria to influence translation of the source addresses.
  • In the pre-8.3 CLI the number “1” is the NAT_ID, which creates the relationship between the nat and global commands.
  • The original syntax (pre-8.3) employs an Access Control List (ACL) in conjunction with the nat command to insert the destination-based rule.
  • In the new model introduced by release 8.3, we use manual NAT to create any rules that concurrently involve source and destination. This is the case for Policy NAT, Policy PAT and Dual NAT. Unless you use the after-auto argument in the nat command, manual translations are inserted in Section 1 of the Unified NAT Table.

Dynamic Policy PAT on ASA

** Notes:

  • As in the basic PAT case (which does not take destination addresses into account), ASA combines the global address (172. 16.16.125 in this case) with a source port to correctly identify each internal host and deliver the return packets accordingly.
  • Manual NAT allows you to add a sequence number to each manual nat statement, so that you can directly control the order of processing of the translation rules (irrespectively of the NAT category in place). This is a major difference when comparing to releases up to 8.2, for which you needed to know the intrinsic NAT precedence rules.

** Topics for Study:

** Related Posts:

Advertisements

Leave a comment

Filed under English, Firewalls, Security

Dynamic NAT on ASA: before and after release 8.3

[“All appeared new, and strange at first, inexpressibly rare and delightful and beautiful. I was a little stranger, which at my entrance into the world was saluted and surrounded with innumerable joys.” – Thomas Traherne]

After reading the article “NAT Evolution within Cisco ASA software” and applying that knowledge to build static translations on ASA, it is now time to implement dynamic rules. As we did before, to make life easier on migration tasks, the two configuration modes (pre and post-8.3) are presented.

The figure below brings not only the old-style syntax but also the new options for a simple topology, in which the internal addresses belonging to the 10.10.10.128/25 subnet are translated to the range 172.16.16.129-172.16.16.254. In this arrangement, some facts deserve special mention:

  • In the legacy CLI the number “2” is the NAT_ID, which is used to establish the link between the nat and global commands.
  • For source-only translations, the nat statement (configured under the network object definition) automatically places the rule in Section 2 of the Unified NAT Table.
  • Given that manual NAT allows the creation of rules that simultaneously specify translation of source and destination addresses, manual NAT can be “simplified” to create source-only (or destination-only) rules. In this case the rule will be part of Section 1 and there will be no reference to network object. Considering that the sections in the NAT table are sequentially processed, the equivalent construction with manual NAT takes precedence over Object NAT. (The exception is when you employ the after-auto parameter in the nat command, thus sending the manual rule to Section 3).

Dynamic NAT on Cisco ASA

** Topics for Study:

** Related Posts:

Leave a comment

Filed under English, Firewalls, Security

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:

2 Comments

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:

4 Comments

Filed under English, Firewalls, Security

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: https://alexandremspmoraes.wordpress.com/tag/ipv6/

ACL Series: https://alexandremspmoraes.wordpress.com/tag/acl/

Leave a comment

Filed under English, Firewalls, IPv6, Security

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