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.
If the Cisco determines that the connecting device is behind a NAT, it flips to NAT-T - ignoring anything the peer device may do. There appears anecdotally to be some variance around whether and how quickly this occurs. This is not ideal, and due to the possibility for it to change spontaneously, Cohesive considers this behavior a mistake.
WHY IS THIS A PROBLEM?
In nearly any cloud (Amazon, Azure, Google), virtual instances (including VNS3) which have public IPs are actually always behind NAT! However this is a 1-to-1 NAT, which means all ports and protocols can be forwarded correctly to/from the virtual instance. Cisco engineers made the assumption that if an IPsec peer is behind a NAT, their devices should automatically flip to NAT-T. This assumption comes from the early days of NAT; in a cloud-centric world, it is no longer always a valid assumption.
We believe that the best way to maintain stable connections between IPsec vendors is to be as declarative as possible for all connection parameters, matching them up exactly. Some networking teams make the decision that they explicitly wish to use Native IPsec. For various reasons (and Checkpoint exceptions aside), Cohesive recommends against this. We tell customers use NAT-T unless they absolutely cannot. That said, either connection type will work so long as there is no autodetect or flipping behavior.
All that to say, here are the details on how to "declaratively" configure a Cisco ASA (ASR/ISR have similar settings) to use either NAT-T or Native IPsec.
Cisco Settings
There are two places where NAT-T can be configured; the first (located in IKE Parameters) is a system-wide setting to allow NAT-T, and the second (located in Crypto Maps) applies to a specific connection.
Here is a table showing the results of the combined settings:
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.
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. If the Crypto Map NAT-T Enabled checkbox is ticked and the IKE Parameters NAT-T checkbox is not ticket, the connection will not use NAT-T. BOTH checkboxes must be ticked in order to createstable NAT-T connection.
When you run: 'show running config' as shown below, you will NOT see the following 'nat-t disable' entries if NAT-T is configured.
IMPORTANT IF YOU DO NOT USE ASDM - the absence of a specific "disable" command in your running configuration means NAT-T is enabled on the crypto map NAT-T setting. 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 be reviewed by your organization’s networking staff, with appropriate change control mechanisms used to deploy changes.