IPSEC NAT Exemptions & Static NAT's

[ebanksdhhs]

Router A and Router B are IPSEC tunnel peers, using the Internet as the connectivity transport. Routers A & B perform NAT pooling with overload for Internet bound traffic - traffic destined for the remote side of the VPN tunnel is exempted from the NAT overload.

This much works fine. Here's the problem:

Router A also has a few static NAT's to support inbound access of HTTP and SMTP traffic to hosts on the private LAN. It appears that when these hosts on LAN A attempt to contact a host on LAN B via the VPN tunnel, the NAT exemption doesn't take effect - the traffic is sent out to the Internet anyway via the static NAT.

So - the question is, how do I work around this?

[gfullage]

The following sample config will get you going, it has a good explanation of what's happening also:

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080094634.shtml

[murali.sethuraman]

Hi,

I recreated the same setup in a lab environment but after the route-mapidentifies the packets and send them to the loopback address as the next-hop the packet is never seen in the IPSec tunnel. The router also complains that the next-hop is the same router. If you look at the cco example closely, you will also notice some errors in the loopback IP address.

Is this setup really working and if yes, is this supported from a specific IOS code.

Thanks for your response!

Best regards, Murali

[ebanksdhhs]

I am using the exact method defined in the document, and it works great. I think you're making the same mistake that I made though. The document refers to building a loopback address of 1.1.1.1 and setting an ip next-hop in the route-map to 1.1.1.2. I assumed that was a misprint, and that they really wanted me to set the ip next-hop to 1.1.1.1 - well, they don't. They really mean 1.1.1.2, even though that IP doesn't exist anywhere. What I believe happens is that the packet is forwarded to the loopback interface, because the router believes that the 1.1.1.0/24 network is directly connected there. The packet is forwarded to 1.1.1.1, with the expectation it will get to 1.1.1.2. 1.1.1.2 doesn't really exist, so the router re-evaluates the packet for forwarding. At that point, there's no NAT to be performed, because the packet isn't leaving a "ip nat inside" interface.

Anyway, it is working for me, but you do have to follow the document exactly.

HTH!

[murali.sethuraman]

Hi,

Thanks for your reply. I am sure must be making the mistake of understanding the document.Thanks once again for highlighting it. Will try again in my setup.

Have a good day & best regards,

Murali