IOS VPN peer identity IP validation with NAT-T

[tgrundbacher]

I've just lost a lot of time by figuring out this behaviour of IOS. My attained conclusion: If you work with good old peer identity address validation in ISAKMP profiles and the peer you speak to sits behind NAT, you have to use the private IP of the peer in the 'match identity address' command. I thought that NAT-T takes care of the translation in all necessary config sections, but here specifically, it doesn't seem so. The interesting thing is, that for all other commands, you have to use the public IP.

See the following example (only showing relevant sections with peer statements in them):

crypto keyring OUR_KEYRING

  pre-shared-key address 1.2.3.4 key <key>

crypto isakmp profile PROFILE_NAME

   vrf TEST

   keyring OUR_KEYRING

   match identity address 192.168.99.5 255.255.255.255

crypto map OUR_MAP 6 ipsec-isakmp

  set peer 1.2.3.4

  set isakmp-profile PROFILE_NAME

Does anybody know if this is by design or if this is a bug? It would be useful and consequent if NAT-T changed the peer identity address in the phase 1 negotiation so we would not have to deal with private peer addressing within site-to-site VPN configs. I'm also thinking of overlapping IP scenarios that could arise when working with private peer addressing.

See the relevant debug output in the attachment, once documenting a failing connection attempt (using the public, NATted IP of the peer in the 'match identity address' command) and once a succeeding connection attempt (using the private, internal IP of the peer).

My router is a C2951 with IOS 15.3(2)T2. The peer is an ASA (version & config unknown so far, but I'm sure the other engineer didn't set anything up using a private address in his config, despite my router sitting behind NAT, too).

Thanks & regards

Toni

[Marcin Latosiewicz · Accepted solution]

Toni,

Problem with identity is that it's an encrypted packet (in MM exchange) thus cannot be changed in transit, plus a host cannot know reliably it's external IP address (it can make some assumptions but it would not know how long it's valid for).

Also if you "NAT'd" the identity you could not differentiate between two devices behind same NAT/PAT on responder end. 

There are some IKE implmentations which allow IKE identity type and value to be specified manually. IOS not among them.

Yes we decouple identity and peer IP, it adds flexability with a few corner cases which can arrise.

Yet another reason why NAT is evil?

M.

[tgrundbacher]

Thanks Marcin, it all makes sense again...I've forgotten the theory part Aggressive mode would change the situation, since the ID is not protected there, right?

So how could you support different routers behind the same NAT IP if the rest of the commands (keyring, crypto map) require the public IP?

[Marcin Latosiewicz]

That would (obviously?) work only if we are the responder.

You can differentiate different peers with (both recommended)

1) Different dynamic crypto map entires with specifiec "match" statments. AND binding to:

2) Different ISAKMP profiles binding the internal IP address to features

[tgrundbacher]

OK...and then by having to use certificates or 'pre-shared-key hostname ' instead of 'pre-shared-key address ' if you want to use different credentials, I guess.

Thanks Marcin.