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

Original problem was posted on 20-Dec-2005 under the subject "*some*
return traffic not going through vpn tunnel (although not all)".

The problem was traced back to a NAT problem where VPN tunnel traffic
using the same port number as static port mapped NAT traffic was not
being returned to the user. Applying route-maps to the static NAT
entries solved the problem. Alternatively one could use IP policy
routing.

For example:

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
access-list 110 permit ip 10.0.0.0 0.0.0.255 any

route-map SDM_RMAP_1 permit 1
match ip address 110

ip nat inside source route-map SDM_RMAP_1 interface Dialer0 overload
ip nat inside source static tcp 10.0.0.209 25 interface dialer0 25
route-map SDM_RMAP_1
ip nat inside source static tcp 10.0.0.209 80 interface dialer0 80
route-map SDM_RMAP_1
ip nat inside source static tcp 10.0.0.209 443 interface dialer0 443
route-map SDM_RMAP_1

 

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
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

 

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