Hi Marwan,

First of all,

ip nat inside source static esp {ip} {ip}

is not supported,

but

ip nat inside source static esp {ip} {interface}

I've tested this using c2800nm-spservicesk9-mz.124-3f.

I'm wondering how to realize it with the interface option

Any suggestions please?

I tried something like this,

ip nat inside source static 10.0.1.2 185.0.1.5 route-map TEST reversible

route-map TEST permit

match ip address 101

access-list 101 permit esp host 10.0.1.2 host 197.20.20.1

Also I've applied,

ip nat inside on 10.0.1.2 connecting interface and

ip nat outside on interface connecting to the remote peer.

In my opnion udp 500 is not required in this case (Manual Keying).

What do you think about this?

Thanks for your comments and suggestions.

why u doing it like this long

just nating as i told u

without route map easier to config and to troubleshoot

this is a complete example will help u alot just follow the concepts and config then let me know

Interface s2/0 is the NAT inside address

!

interface Serial2/0

ip address 10.10.10.2 255.255.255.0

ip nat inside

!

!

! Interface serial 2/1 is the NAT outside address

!

interface Serial2/1

ip address 192.168.3.1 255.255.255.0

ip nat outside

!

!

! The static translations here allows the Berlin gateway to initiate IPsec

! connections to the London gateway.

!

ip nat inside source list 10 interface Serial2/1 overload

ip nat inside source static esp 10.10.10.1 interface Serial2/1

ip nat inside source static udp 10.10.10.1 500 interface Serial2/1 500

!

access-list 10 permit 10.10.10.0 0.0.0.255

good luck

Thanks for sharing an example Marwan.

If the interface command option is applied it will simply take the IP of the outside interface as the local peer, right?

If you have a closer look into my scenario, you'd see that I need it to take the IP of an inside host connecting to a 3rd interface, instead.

Have I overlooked something here?

ok no problem

it is right should be interface

bu i have put it like this to make easier for understanding

what u mean how realize it ?

when you put interface and the interface type/number

it will consider the ip address configured on that interface

so if your ouside interface configured with 10.0.1.1 so it will be mapped from 10.0.1.1 to the other ip in the nat statment

I don't think we could achieve this with the interface option.

then why u dont use ur outside interface?

also try the following but i am not sure

lets say the outsid einterface of the remote router 2.2.2.2

access-list 100 permit ip host 2.2.2.2 host (the destination ip u want)

route-map map1 permit 10

match ip address 100

set ip next-hop 10.0.1.2

then apply this with policy-map statement on the outside interface

again never tried it with IPsec

good luck

The NAT with route-map(I posted previously) works for locally originated (interesting) traffic.

However when the remote side initiates the tunnel it does not seem to come up. What you've proposed with your route map may be used in this case.

But I'm not sure whether you could run ip nat outside and ip policy route-map on the same outside interface to control outbound and inbound traffic respectively.

i am stil wondring why u dont use ur external interface as the termination point for vpn

which is the best practice and will solve ur problem !!!!

No, Marwan as I said this was encountered during a network migration process which has to be performed without any intervention by the remote party.

Actually the current peer is 185.0.1.5, if you consider the scenario. So the idea is to change it with a different peer device, pretending it to be the same in IP network layer. That's why the new device 10.0.1.2 is there acting as 185.0.1.5 to the remote peer.

I understand your point very clearly. However in my opinion, this is where we need to have ideas and workarounds to cope with such situations.

What I have realized is a NAT route-map with Outside-to-Inside support;

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtnato2n.html#wp1046681

The feature design says that an initial session from inside-to-outside is required to trigger this NAT translation(This is exactly what I see with my setup).

However, practically in my case the tunnel needs to be initiated by the remote-side as well.

This can be accomplished relatively easily with Posix/Iptables and hoping it would be the case with Cisco too.

Hi,

Any suggestions with regard to remote peer initiated IPSec tunnel deployments please?

I am unable to get it working with route-map for ESP traffic.

Thanks for your thoughts and time.

why you cannot use just simple

ip nat inside source static ip 10.0.1.2 185.0.1.5

?

thats what i have been mentioning either static nat

or static pat (port forward)

ip nat inside source static ip 10.0.1.2 185.0.1.5

or

ip nat inside source static esp 10.0.1.2 185.0.1.5

ip nat inside source static udp 10.0.1.2 500 185.0.1.5 500

this will simply map any connection to 10.0.1.5 to 10.0.1.2

for the first command

with the second two command u gonna map only vpn

ur case maping matter

in other words NATING