09-11-2008 01:29 PM - edited 03-06-2019 01:19 AM
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?
09-11-2008 02:58 PM
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.
09-12-2008 08:07 AM
Thanks for the pointer to the document. Unfortunately "Outside-to-Inside support is not available with Port Address Translation (PAT)."
09-11-2008 02:59 PM
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.
09-12-2008 10:10 AM
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
09-12-2008 10:12 AM
Excellent... I'll try it out later today.
Thanks
09-12-2008 10:36 AM
Cool. My config works from previous client(s) installs, however I haven't tested that link yet.
Have a great weekend!
JB
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide