Networks A (192.168.1.0/24) and B (172.16.1.0/24) both use 1721 routers and support ipsec vpn clients. (This question has nothing to do with site-to-site vpn.) Both networks use the same 10.10.10.1 - 10.10.10.254 ip address pool for their vpn clients.
Host A is behind the 1721 on network A. Using the Cisco VPN Client, he successfully establishes a vpn tunnel with the 1721 on network B. Behind the 1721 On network B is host B which is running a vnc server.
Host A successfully opens a console session on host B using vnc. From within the console session, host B tries to establish a vpn connection to the 1721 on network A using the Cisco VPN Client. Key exchange fails and the connection attempt quits before getting to the prompt for username and password.
Am I correct in thinking that this due to both vpn router endpoints using the same vpn address pools? Would this situation resolve itself simply by insuring no overlap, i.e. 10.10.10.1 - 10.10.10.127 for network A and 10.10.10.128 - 10.10.10.254 for network B? Or would I have to go so far as to using pools on completely different class C address blocks, i.e. 10.10.10.1 - 10.10.10.254 for network A and 10.10.20.1 - 10.10.20.254 for network B?
> can host b ever make a vpn connection (i,e, locally, and not with
> someone driving it via vnc)?
Yes, host B has no problem making a vpn connection (when instructed to do from a local console as opposed to a remotely generated console session like with vnc).
> I would tend to think that the problem is that the with the ip pools.
> I would simply use different pools completely to avoid this chaos.
I went ahead and did the experiment by assigning a vpn pool of 10.10.20.1 - 10.10.20.254 to network B while keeping the vpn pool 10.10.10.1 - 10.10.10.254 assigned to network A. The results are best described as hokey/sporadic as sometimes host B will be able to make vpn connections to network A (driven by vnc over a vpn tunnel by host A). Regrettably the results are not consistent.
Taking it even further I have tried daisy-chaining in the sense: Host A makes a vpn connection to network B. Once the tunnel is established, host A creates a vpn console session with host B. Host B then attempts to make a vpn session to network C. In rare instances host B can establish a vpn console session with host C. Host C sometimes can establish a vpn console session back to network A.
Frankly the results are so sporadic and un-reproducible as to be inconclusive. I have even tried to mix up the remote connection technology by using w2k terminal services connections and winXP remote desktop connections. Nothing has served to vindicate or exonerate vnc or any of the other remote connection technologies.
> also, do you have split tunnelling enabled? What do those statements
> look like?
I have established that split tunneling is working as one would hope and expect.
On network A, the pertinent lines from startup-config are:
ip nat inside source list 110 interface dialer0 overload
ip local pool myvpnippool 10.10.10.1 10.10.10.254
! <100 - vpn split-tunneling>
access-list 100 permit ip 192.168.1.0 0.0.0.63 10.10.10.0 0.0.0.255
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...