conflicting vpn ip address pools?

[jagoe]

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?

[mostiguy]

can host b ever make a vpn connection (i,e, locally, and not with someone driving it via 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.

also, do you have split tunnelling enabled? What do those statements look like?

[jagoe]

Thanks for your reply.

> 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

! <110 - nat addresses - interface d0 (nat dialer)>

access-list 110 deny ip 192.168.1.0 0.0.0.63 10.10.10.0 0.0.0.255 !no nat for vpn addresses

access-list 110 permit ip 192.168.1.0 0.0.0.63 any

!

crypto isakmp client configuration group vpn-client-group

key key-key-key

dns 192.168.1.5 192.168.1.3

domain mydomain.com

pool myvpnippool

acl 100 ! split-tunnel