I want a conditional "ip nat inside source static"

[thomasdzubin]

I have two sites, connected by a ipsec tunnel and everything works fine EXCEPT when I have a "ip nat inside source static" statement needed to access services from the public IP address.

interface FastEthernet0

ip address x.x.x.x 255.255.255.0

ip nat outside

crypto map outside_map

ip nat inside source static tcp 10.1.0.5 3389 interface FastEthernet0 3389

When my second site tries to RDP (port 3389) to 10.1.0.5 via the IPSEC tunnel, the RDP fails and I think it's because the "ip nat inside source static" kicks in and translates the packets which is not what I want when the packets are internal to the company.

How can I do a "ip nat inside source static" statement but not have it kick in for packets that are coming in via the IPSEC tunnel?

[rsgamage1]

You could possibly try using static NAT route mapping Outside-to-inside.

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

Reversible option is there for return traffic, however, it works only when the IPSec tunnel is initiated by a local entity.

I had a workaround for this sometime back, that is to trigger this by using locally originated IP SLA traffic so that the tunnel would be up throughout(in order tackle the tunnel idle timeout). I'm not quite sure how relevant this particular part for your design, though hope it would provide you with some directions to solve your issue.

[thomasdzubin]

Thanks for the pointer to the document. Unfortunately "Outside-to-Inside support is not available with Port Address Translation (PAT)."

[rsgamage1]

You could possibly try using NAT route mapping - Outside-to-inside.

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

Reversible option is there for return traffic, however, it works only when the IPSec tunnel is initiated by a local entity.

I had a workaround for this sometime back, that is to trigger this by using locally originated IP SLA traffic so that the tunnel remains up throughout(in order tackle the tunnel idle timeout). I'm not quite sure how relevant this particular part for your design, though hope it would provide you with some directions to solve your issue.

[jpoplawski]

We ran into this situation with Site to Site VPN's and Static NAT entries. The router is attempting to "un-nat" the VPN-ed traffic and push it back to the outside interface NAT translation. Here's what I did to overcome it.

Setup a Loopback Interface:

interface Loopback0

ip address 1.1.1.1 255.255.255.0

Create an ACL for the traffic to go backwards:

access-list 177 permit ip host 10.0.1.20 10.0.2.0 0.0.0.255

where 10.0.1.20 = local server

Where 10.0.2.0 = remote subnet (perhaps your HQ)

Create Policy Based Routing

route-map PBR permit 10

match ip address 177

set ip next-hop 1.1.1.2

Apply PBR to inside interface

interface Vlan1

ip policy route-map PBR

This effectively tells the router to use the loopback to go through the tunnel, instead of using the outside NAT translation.

My explanation could probably be better explained, but I know this works from previous experience. You will obviously have to modify the config to meet your needs.

A different approach to overcome this issue can be found here: http://www.cisco.com/en/US/docs/ios/12_2t/12_2t4/feature/guide/ftnatrt.html

Cheers, rate me if this helps!

JB

[thomasdzubin]

Excellent... I'll try it out later today.

Thanks

[jpoplawski]

Cool. My config works from previous client(s) installs, however I haven't tested that link yet.

Have a great weekend!

JB