solution to "*some* return traffic not going through vpn tunnel (although not all)"
|
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
||||||||||
|
Posted by on January 31, 2006, 12:47 pm
Please log in for more thread options
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 | ||||||||||
|
Posted by on February 2, 2006, 7:08 am
Please log in for more thread options 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 | ||||||||||
|
Posted by Igor Mamuzic on February 4, 2006, 11:47 am
Please log in for more thread options 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  | ||||||||||
|
Posted by on February 8, 2006, 6:55 am
Please log in for more thread options Ah, OK Igor. Then your config would look something like this examplewith 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 | ||||||||||
|
Home Cabling Guide
Finally, an instantly downloadable book that saves you thousands in home improvement dollars! Enjoy living in 21st century technology-advanced home while increasing its selling value and competitive advantage on the real estate market. Whether your cabling is for home office or high-tech leisure, you can wire your home yourself or learn "wirish" to speak with your cabling contractors in their language! Click Here to learn more |
> 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
>