By default, Cisco devices use "auto-discovery" to determine whether the Cisco device will attempt native IPSec (Protocol 50/ESP) or NAT-T (Protocol 50/ESP encapsulated inside UDP 4500) during an IPSec negotiation.  


The Cisco attempts to determine if the connecting device is behind a "NAT" and if so FLIPs to NAT-T EVEN IF THE OTHER DEVICE HAS USED Native/ESP in its initiations.   There appears to be some variance around how quickly this occurs anecdotally, but may just be a function of which device is the INITIATOR.  This is not ideal, and as far as Cohesive is concerned is a MISTAKE.   It can change spontaneously and cause an outage.


WHY IS THIS A PROBLEM?

In "the cloud" (Amazon, Azure, Google) your virtual instances (like VNS3) which have public IPs are ALWAYS BEHIND A NAT! However, since this is a 1-to-1 NAT ESP/Protocol 50 (and other protocols) are forwarded correctly to/from the virtual instance.   


Many customer networking teams take the decision that they WANT to use Native IPsec.  At Cohesive we recommend against this (Checkpoint exceptions aside), and tell customers use NAT-T unless they can't.  That said, it is a customer's choice what they declaratively want to do - and if they want Native - they can configure VNS3 for Native and it won't do anything but Native for that connection.  


We believe way to have stable connections between vendors is to be as declarative as possible for all the parameters and match them up, and if you do, the connection will be stable for ever (or until you change it).


Cisco engineers have made the mistaken assumption that if you are behind a NAT that their devices should automatically flip to NAT-T.   They are operating under old-world, metal assumptions about how the world works - and the cloud doesn't work that way.  


SO - here is the detail on how to make your Cisco ASA (ASR/ISR have similar settings) be set as "declaratively" as possible to either do NAT-T or Native for a connection.


Cisco Settings

There are two places where NAT-T can be configured; the first (set in IKE Parameters) is a system-wide setting, and the second (set on the Crypto Map) applies to a specific connection.


Here is a table showing the results of the combined settings:


nat-table-vns3.png


Here is a screenshot showing the "system-wide" setting in IKE Parameters.  If this checkbox is not ticked, no connections on the device will be able to use NAT-T.cisco1.png




The following screenshot shows the NAT-T setting for a specific Crypto Map; this is where you should configure the NAT-T setting for a specific connection.  You will not be able to use NAT-T if the checkbox on the IKE Parameters page is not ticked.


cisco2.png



When you run: 'show running config' as show below you will NOT see the following 'nat-t disable' messages if NAT-T is configured.



THIS IS IMPORTANT IF YOU DON'T USE ASDM - the absence of a specific "disable" command in your running configuration MEANS NAT-T IS ENABLED. If you want Native IPsec/Protocol 50 you MUST have the explicit disable command. If you do NOT have the specific disable command and the other device is behind a NAT (all devices like VNS3 in Amazon, Azure, Google are behind a NAT), even if the cloud side device is explicitly configured for Native IPsec/Protocol 50, you will end up with the Cisco sending phase2 traffic using either UDP 4500, and in some versions of ASR/ISR via UDP 500.




NOTE: This work was done in the Cohesive Networks test environment and should still be reviewed by your organization’s networking staff, and appropriate change control mechanisms used to deploy changes.