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

Discussion in 'Cisco' started by b0rez, Jan 31, 2006.

  1. b0rez

    b0rez Guest

    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
     
    b0rez, Jan 31, 2006
    #1
    1. Advertisements

  2. b0rez

    b0rez Guest

    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
     
    b0rez, Feb 2, 2006
    #2
    1. Advertisements

  3. b0rez

    Igor Mamuzic Guest

    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
     
    Igor Mamuzic, Feb 4, 2006
    #3
  4. b0rez

    b0rez Guest

    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
     
    b0rez, Feb 8, 2006
    #4
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.