1.5.1 FTD & ASA NAT – Introduction


In this series of posts, I’m going to discuss NAT on Firepower and the ASA in the way that I comprehend it. For this post I don’t plan on to getting too far into the configuration and verification aspects, we’ll dive into that later.

It’s not as complex as it looks.  Really.

In my opinion this is one of those topics where the difficulty level can be measured by the quality of your foundation knowledge. Put plainly – if you can clearly visualize what the traffic flow should look like, then it’s easy.   The actual configuration syntax is easy to learn and work with.  And although the configuration interface may look different, there is in actuality zero difference between FTD and ASA NAT.  So you only have to learn it once for both platforms, nice right?!?

Armed with these insights, let’s do a level set on traffic flows.  This baseline will give NAT syntax and semantics their context, so please at least skim it.  You can always come back to it as needed.

The 5 tuple flow (and stateful firewalls).

A unique IP traffic flow is defined by 5 fields.

  • Source IP address
  • Destination IP address
  • Transport protocol (Ex: TCP/UDP)
  • Source port
  • Destination port

For the purpose of working with NAT, I find it helpful to visualize this in a left to right fashion like this:

[| | TCP | 50922 | 80]

In this example a device at is communicating with a web server at

A conversation between two hosts can be seen as two unidirectional Flows were the IP addresses and Ports are a mirror image in the reverse direction.

Taking our above example, that is what the two flows in the conversation look like:

[ | | TCP | 50922 | 80]
[ | | TCP | 80 | 50922]

And that’s pretty much what it looks like in a packet capture:

firewall# capture example int inside
firewall# sh capture example

5 packets captured

1: 00:39:03.453925 > […] 1520352048:1520352048(0) win 4128 <mss 536>
2: 00:39:03.459921 > […]


A stateful firewall recognizes these mirror image flows and identifies them as related.  This simplifies usage – we only have to define our traffic rules in one direction, and the firewall can imply how the return traffic should be processed.

This logic also applies to NAT.  If you define the flow in one direction, the NAT engine in the firewall processes the mirror image packets to look for a match.

Note how the firewall sees the two flows as a single connection:

firewall# sh conn
1 in use, 1 most used

TCP outside inside, idle 0:00:07, bytes 0, flags UB

Nat rule types

FTD and the ASA have two types of NAT rules:  Auto and Manual.

Auto Nat

Auto NAT is the simplest and easiest form of NAT to configure.  I think of it as the microwave popcorn button of NAT.    We define a network object, then attach a NAT statement to the object that tells that firewall what translation we want to perform based on the source and destination interface.

Here is a basic example:

Object network Server-A
nat (inside,outside) static

This is how the fields relate to the flow:

Original packet:
[ | | TCP | 80 | 50922]
Translated packet:
[ | | TCP | 80 | 50922]

The individual components:.

Host – The firewall will evaluate this against the first interface in the NAT statement.  With object NAT this is always going to be the source IP address

Nat (inside,outside) – The source ip address is coming from the inside interface of the router, and the destination ip address is on the outside interface of the router.  the destination interface is determined by the routing table.

Static – The source and destination address will be linked together in a fixed 1:1 relationship.  This is most commonly used for servers that require a fixed public (mapped) ip address.  Examples would be a web or email server.  – The mapped (public) ip address.  If source address, source interface, and destination interfaces all match, then the firewall will perform the translation.

Here’s what our NAT table looks like with the Auto Nat Rule Configured:

firewall# sh nat

Auto NAT Policies (Section 2)
1 (inside) to (outside) source static Server-A
translate_hits = 0, untranslate_hits = 0

Manual NAT

Manual NAT is useful for more advanced requirements, such as translating multiple fields in both directions, and conditional translation.

Happily, the way the NAT configuration syntax is structured makes it very easy to work with  once one can relate the fields in the flow to how that NAT statements are laid out.

In Manual Nat, the full five tuple flow can be matched and transformed. Be aware that unlike object Nat where the mapped address can be given directly, Manual Nat requires that all addresses/ranges/subnets in the statement be predefined as objects.

Manual NAT basic example:

Object network Server-A
Object network MAP-Server-A
nat (inside,outside) source static Server-A MAP-Server-A

As you can see, when you’re doing simple source translation Manual NAT requires more lines of configuration to accomplish the same result as auto nat.

Here’s what our NAT rule looks like for the above manual NAT example:

firewall# sh nat
Manual NAT Policies (Section 1)
1 (inside) to (outside) source static Server-A MAP-Server-A
translate_hits = 0, untranslate_hits = 0

Let’s look at common use for Manual NAT.  We’ll dive deeper in a subsequent post, This is just to give you a starting example.

Let’s say you’ve configured the Auto NAT translation shown earlier.  You are then asked to create a site to site VPN with a branch office.  In that case, when users from the branch office attempt to connect to Server-A, the auto NAT rule will kick in, translating the source address of the server on the return leg, and traffic will not return over the VPN tunnel.——————————————————————–>
*source IP in return traffic is translated, breaking the flow

So how do we fix this problem?  We use manual NAT to tell the firewall not to translate the address of Server-A when the destination is Branch-PC.  Like This:

Object network Srv-A
Object network Br-PC
nat (inside,outside)  source static Srv-A Srv-A destination static Br-PC Br-PC

Here is the generalized form is what this statement is doing:
(incoming, exit) static source real mapped destination static real mapped

The important thing to grasp is that for both source and destination, we’re setting a condition.  Match this . If all conditions match, then change to this.

We’re telling the firewall, if you have this source and destination pair, Don’t change anything.  This overrides the Auto NAT and allows it and our VPN connection to co-exist.  This a use called Identity NAT.


Nat rule table structure

The Nat rule Table has Three sections.

  1. Manual before auto

  2. Auto

  3. Manual After Auto

The user can set the order of the Manual NAT rules.  The Auto Nat rule order is set by the firewall automatically from most to least specific traffic match.  i.e. a host object would be ordered before a subnet object.

NAT table with Auto NAT rule, plus the identity nat override

firewall# sh nat
Manual NAT Policies (Section 1)
1 (inside) to (outside) source static Srv-A Srv-A destination static Br-PC Br-PC
translate_hits = 0, untranslate_hits = 0

Auto NAT Policies (Section 2)
1 (inside) to (outside) source static Server-A
translate_hits = 0, untranslate_hits = 0

Now a reason to order Manual NAT ahead of Auto NAT makes some sense right?

Wrap up

Well that’s quite a few words for an introduction, so let’s stop here.  In our next post we’ll go deeper into the terminology and usage examples .

3.11 FlexVPN – Flex Server w/Next Generation Encryption. Routing Design, Device enrollment


This is a kickoff post for a series demonstrating the capabilities of FlexVPN server.

Since we’re building up this sample network from a clean sheet of paper, we’re going all in.  We’re going to build ourselves a solid foundation, and then up the ante with high availability and integration with Identity Services Engine down the road.

The base build is going to use Next Generation Encryption (NGE), Elliptic curve certificates, and overlay routing design.  We’ll also demonstrate how we can support a site with an older design (firewall w/crypto maps) with the exact same head end.

In this installment, we’re going to review the routing design, cryptography suite selection, and enroll our devices with shiny 384 bit elliptic curve certificates.

Included at the end of this post are links to useful documents.



Great slide deck on FlexVPN

Densemode Labbing Topology 1

Cisco Next Generation Encryption Techology Document

Tim Glen breaks down Diffie Hellman Groups

RFC 6379: Suite B Cryptographic Suites for IPsec

Elliptic Curve Cryptography

3.10 FlexVPN Smart Defaults


In this installment we’re going to take a quick look a the main configuration blocks for FlexVPN on Cisco IOS devices.  then we will take advantage of smart defaults to turn up a tunnel with just a handful of commands.

Here’s the config from the video.  As you can see it’s ridiculously easy to use. There’s 5 lines of config that relate to ipsec.  That’s it.

PKI for Network Engineers (9/?): Elliptic Curve Setup

Greetings fellow networkers,

In this installment of PKI for network engineers, we’re going to build up our two tier Elliptic Curve PKI hierarchy in one shot.  There are a lot of tasks, but only a few of them differ from our RSA setup.  I’ll highlight those below.

  1. Cryptographic service provider and Hash algorithm.
    1. I’m using ECDSA 384 and SHA384
      1. Although the Microsoft CA supports 521 bit EC Keys, Cisco IOS maxes at 384
  2. No NDES/SCEP.  NDES supports RSA only for in-band device enrollment
    1. There is a new standard called EST (enrollment over secure transport)
      1. IOS and IOS-XE support EST as clients
      2. There’s an open source project called libEST you can use to test.
      3. Cisco ISE as of version 2.2 supports EST
  3. Web enrollment doesn’t support version 3 or 4 templates
    1. When duplicating templates, be aware of this fact
  4. Mind your signatures and public key algorithms.
    1. RSA public keys can be signed by a EC CA and vice versa.  Keep this in mind when creating your templates and take care to test them and inspect your certificates to make sure you’re getting what you think you’re getting




Settings, scriptlets, helpful text blocks:


PKI For Network Engineers (8/?) Windows Certificate Autoenrollment

Greetings Programs!

In this installment of the series, we set up the Active directory plumbing needed to do Certificate Autoenrollment for users and computers, and then we test it.  In the vein of the series, rather than taking defaults which are often not the best idea in a production network, we build things up in a more realistic manner.

In addition to learning how to set up auto enrollment, if you follow along, you’ll get some practice in doing some basic windows sysadmin including creating users, groups and organizational units, creating group policy objects, and most importantly working with certificate templates.

As usual, I included some links of interest at the bottom.

Happy labbing!

configuring Certificate Autoenrollment: https://technet.microsoft.com/en-us/library/cc731522(v=ws.11).aspx

Troubleshooting Certificate Autoenrollment:  https://social.technet.microsoft.com/wiki/contents/articles/3048.troubleshooting-certificate-autoenrollment-in-active-directory-certificate-services-ad-cs.aspx



PKI For Network Engineers (7/?): Network Device Enrollment Service (SCEP)

Greetings fellow Networkers!

In today’s installment, we’re going to configure network Device Enrollment Service, Microsoft’s implementation of SCEP.  Then we’ll enroll a router in-band.

A couple of things to note:

  1. By Default, NDES requires a one time password for enrollment.  This can be disabled via registry key.
  2. SCEP does not work with Elliptic Curve Certificate Authorities.  Enrollment over Secure Transport Supports in-band EC enrollment and is considered the successor to SCEP.
  3. I attached a pcap of all SCEP activity between the router and the CA.  if you look at the Cisco doc, it’ll explain what’s happening so you can interpret the activity in the PCAP.



PCAP of SCEP activity in video:  https://www.cloudshark.org/captures/62d72e489181

SCEP RFC: https://www.ietf.org/id/draft-gutmann-scep-06.txt

Cisco TechNote on SCEP (very well written):   https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/116167-technote-scep-00.html

Microsoft Guidance on installing and configuring NDES: https://technet.microsoft.com/en-us/library/hh831498(v=ws.11).aspx



PKI For Network Engineers (6/?): Web certificate Enrollment

Finally!  After all the work we’ve done, we get down to the business of actually issuing a certificate to a router.  We set up the web enrollment service, configure a template, and enroll a router.

At the very end I also point out a few things about the issued certificate.  With all the work we’ve done to this point, it’s cool to see it all being put to use. I didn’t go in to a lot of detail because I wanted to keep it short, but I think it’s really worthwhile to study the certificates you issue from your lab pki and learn what the different fields are and what they are used for, and how they relate to the configuration of your pki.

Here are snippets of the different commands I used on the router in the video.


In the next installment we’ll look at network device Enrollment service, which is Microsoft’s implementation of SCEP.

Thanks for watching and I hope you find this helpful.


PKI for Network Engineers (4/?): RSA Enterprise CA setup

Greetings Fellow Geeks!

In this post, we’re going to set up our enterprise issuing CA for RSA based certificates.

The workflow is pretty straightforward.  The steps are:

  1. publish root Cert to AD
  2. add root cert and crl to local store
  3. install services
  4. configure CDP and AIA extensions
  5. run scripts
  6. copy enterprise cert to web server and rename
  7. publish CRL and Delta CRL

Here are text snippets to help out if you would like to follow long and build your own issuing CA while watching the video:


The video came out a little bit long due to some troubleshooting at the end, but I think it showed a couple of helpful things about checking the details of your certificates and fixing mistakes.  Let me know if you think this is too long and I’ll make a shorter version.


PKI for Network Engineers (2.5/?): Web Server basic Setup


In this post we’re going to take a quick walk-though of the the web server that will host our Root certs, CRLs (certificate revocation lists) and act as the Online Responder for our CAs.  This server is referenced in the AIA and CDP fields of the certificates we issue, so clients will check with this server as part of the certificate validation process.

Because this is the place clients always come to check certificate validity, high availability is important.  In a production install this would be two or more servers ideally sitting behind a load balancer with a virtual ip address.



Happy labbing!



PKI for Network Engineers (3/?): RSA Offline Root

Greetings Professor Falken,


How about Global Thermonuclear War  setting up a two level CA hierarchy?  This is great configuration for labbing and for medium to largish enterprises.  As I discussed at the end of part one of this series, you would never want to deploy an enterprise root in a real network.  So why not model best practices in our lab?

Ok, let’s get started.

NOTE:  Before we configure anything, it’s important to do some planning and sort out all the naming conventions.  If you want to follow along with the videos, check out the attached: Setup Text Block File and a Diagram  which you can edit to customize for your lab.  I also included links to some resources in the doc.  I found Timothy Gruber’s guide on setting up Windows 2016 PKI enormously helpful.

There’s a lot of work to be done, so I’ll break it up into 15-20 minute chunks.

In this video we set up the offline root.