Cisco IOS - Remote Access VPN - unwanted route problem
I have run into a problematic scenario recently: I am trying to connect from a remote LAN (using a Cisco VPN client on my windows xp machine) to my office LAN and access one server there. The problem is that I need access to the entire remote LAN at the same time.
To provide the access, I configured a simple remote-access VPN on an 1700 series router. This is the relevant part:
crypto isakmp client config group group-remote-access
ip local pool vpn-address-pool 172.16.55.1 172.16.55.30
access-list 100 permit ip host 172.16.45.100 172.16.55.0 0.0.0.31
The configuration works fine, in that I can access the 172.16.45.100 server whenever I need to. However, the problem is that when the VPN link is connected, Windows somehow wants to route any packet destined for 172.16.0.0/16 through the VPN tunnel! This is apparently due to a static route which added by the Cisco VPN Client along with all the other VPN-specific routes.
I suspect the culprit is the IP LOCAL POOL, since when the VPN is connected, the VPN Client debug log shows something like "Adapter Connected, address 172.16.55.1/16". Emphasis on the "/16" part. I checked the status page for the VPN connection and the only route specified there was "172.16.45.100 255.255.255.255" under Remote Routes. Local Routes was empty.
Is this a known problem that I missed the obvious solution for? Is there any workaround aside from moving the local vpn pool into the 10.x.x.x or 192.168.x.x range? Thank you in advance for any tips or hints!
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...