Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

solution: PAT interferes with VPN routing

OBSERVATIONS:

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.

CAUSE:

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.

SOLUTION:

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

ip nat inside source static tcp 10.0.0.200 25 interface dialer0 25

route-map no-dynamic-nat permit 1

match ip address 110

route-map no-static-nat permit 1

match ip address 111

set ip next-hop 1.1.1.2

access-list 110 deny ip 10.0.0.0 0.0.0.255 10.10.10.0 0.0.0.255 ! no nat for vpn addresses

access-list 110 permit ip 10.0.0.0 0.0.0.255 any

access-list 111 permit tcp host 10.0.0.200 eq 25 10.10.10.0 0.0.0.255 !smtp

interface FastEthernet0/0

description - secure network

ip address 10.0.0.250 255.255.255.0

ip policy route-map no-static-nat

ip nat inside

interface loopback 0

ip address 1.1.1.1 255.255.255.0

COMMENTS:

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.

257
Views
0
Helpful
0
Replies