solution to "*some* return traffic not going through vpn tunnel (although not all)"

Actually this post is incorrect in light of discovering the IOS was hiding the fact that it really was not applying route maps to the static PAT entries. The definitive workaround is posted in the Cisco Networking Professional forums:

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

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

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:

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

In IOS 12.4(4)T I didn't noticed such issues. I have portless static NAT that I'm using to publish my smtp server. So, I applied route-map onto this static NAT so that IOS don't translate returning traffic when VPN clients are trying to communicate with smtp server's internal ip address. And it works...

B.R. Igor

Ah, OK Igor. Then your config would look something like this example with 10.0.0.200 being your inside smtp server:

ip nat inside source route-map no-dynamic-nat interface dialer0 overload ip nat inside source static tcp 10.0.0.200 interface dialer0 route-map smtp-only-nat

route-map no-dynamic-nat permit 1 match ip address 110

route-map smtp-only-nat permit 1 match ip address 111

access-list 110 deny ip 10.0.0.0 0.0.0.255 10.10.10.0 0.0.0.255 access-list 110 permit ip 10.0.0.0 0.0.0.255 any

access-list 111 permit tcp any any eq 25 access-list 111 deny any any

Have I understood this correctly?

-boris