ASA outside to inside port conflicts different IP's?

[cco@leferguson.com]

I started to implement ikev2 tunnels on an ASA and when I went to enable ikev2 I got: 

# crypto ikev2 enable outside 
ERROR: Failed to open "udp/localized/2/4500" 
ERROR: Error opening IKE port 4500 on Interface outside

This ASA it turns out is passing unrelaetd traffic through to an interior tunnel router, but from a different nat address on the same interface.  The default interface address is (let's say) 1.2.3.4 but the address used to pass tunnels is 1.2.3.6 (substituting IP's for names) 

object network 10.1.2.3
 nat (TUNNELS,outside) static 1.2.3.6

And associated access list: 

access-list OUTSIDE-IN-TRAFFIC extended permit esp any4 object 10.1.2.3 
access-list OUTSIDE-IN-TRAFFIC extended permit udp any4 object 10.1.2.3 eq isakmp 
access-list OUTSIDE-IN-TRAFFIC extended permit udp any4 object 10.1.2.3 eq 4500 

Note that this current 1.2.3.6 passthru is working and in production and I need to avoid breaking it. 

I think what is happening is that despite being (through the NAT statement) bound to a specific and different IP address, the access list appears to be marking port 4500 in use on the all IP's on the outside interface, so ikev2 cannot enable.  

There is no conceptual collision because the inbound connections that are passed thru are to a different IP address, but I cannot find a way to specify that address in the access list (new style, old style I guess you could). 

I realize that it may be possible to avoid 4500 on the current pass-thru devices be re-provisioning them, but they are all configured and in the field (on mobile devices). 

So questions: 

Am I correct that the conflict is occurring because of the access list? 

Is there anyway to separate these, so port 4500 can be used both on the default IP address for the interface for ikev2 tunnels, and still pass port 4500 through on a separate nat'd external IP address? 

Linwood

[Rob Ingram · Accepted solution]

cco@leferguson.com is there any active nat translation for udp/4500 behind the outside interface?

Run "show xlate | inc 4500" to confirm.

You could then run "clear xlate" this would clear all active translations. Though you can be more specific "clear xlate lport|local|global|gport" run "clear xlate ?" to see all options.

Once the xlate is cleared enable ikev2, hopefully the other nat translations will establish connection on another port rather than 4500.

[cco@leferguson.com]

That (show xlate) is the command I was missing  Yes, there are some and coming from our guest network.  

The clear xlate allowed me to fix it, though it took some fast typing as they kept reappearing, but I assume it will "stick" now that the ikev2 is enabled. 

Thank you thank you thank you!  I was assuming it was the other NAT, never occured to me something would use it directly, but obvious now.  Thanks again.