It was observed that statically port-mapped NAT routes interfere with return traffic to a VPN client. For example, consider an 1841 configured as a VPN endpoint as well as an internet gateway firewall/router that performs PAT on all incoming port 25 traffic: When a remote host attempts a port 25 telnet session on the outside IP address of the router, they are connected to the SMTP server on the secure LAN. However, if they attempt a port 21 telnet session, naturally they are not connected because there is no corresponding PAT entry.
Now consider the same remote host establishing a VPN tunnel to the 1841. When they attempt a port 21 telnet session to an FTP server on the secure LAN, they are connected. However, when they attempt a port 25 telnet session to the SMTP server on the secure LAN, they are unable to connect.
Attempts to apply a route map to a static PAT entry are not supported in IOS 12.3(8)T6 and before. Although the route map *can* be entered at the command line and in startup-config, there is no indication there is something wrong. In reality, the IOS creates a static NAT route (port-less) between the outside interface and the inside host, something terribly problematic if multiple port address translations to different inside hosts are required.
This problem pertains to router-to-router VPN tunnels, as well as tunnels between Cisco VPN clients and VPN endpoint servers running on routers. The same behavior has been witnessed on 806, 827, 1721 and 1841 routers.
Owing to the static NAT route for port 25 traffic, the return packets are routed back out through the 1841's public ip interface, rather than back through the VPN tunnel. As a result, a TCP/IP session is not established between the two hosts.
Using an IP policy on the NAT inside interface to redirect packets to a non-NAT'd loopback interface, the packets are routed correctly back through the VPN tunnel, regardless of PAT on the router's outside interface. The original idea for this workaround came from a web forum: http://www.mcse.ms/message900530.html
ip nat inside source route-map no-dynamic-nat interface dialer0 overload
SDM 2.0 was absolutely useless in identifying the problem or a solution.
Future versions of IOS should support either ACLs or route maps for static port address translations to avoid this rather obtuse workaround. ACLs and port maps are already supported for static network address translations.
Strangely, there is a dearth of information about this problem in Cisco forums and elsewhere on the internet. Yet, I have to believe that it affects hundreds, if not thousands of installations all over the world. In my own case I simply lived the problem for two years because I never had the time to roll up my sleeves and get to the bottom of this mess. Perhaps everyone else is doing the same thing; hopefully this will be useful to some of you out there.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...