I have 3 networks:
A - Vendor's network
B - My network
C - Client's network
For connections to my client's network, I initiate Cisco software VPN client for a connection from B to C. This works with no problems.
I now have a vendor on board who wants to provide services to my customer. For reasons I can't go into, the vendor cannot initiate VPN connection from A to C. They have to initiate VPN connection from A to B (and then RDP into my Windows box on the B network).
When the vendor tries to initiate VPN from B to C, their RDP session is terminated. This is of course because in the act of making the VPN connection, their own VPN connection (from A to
is terminated. I can log in to the machine on my network, and the B to C connection that was initiated by the vendor is always successfully made, but they have been booted from the RDP, and can never reconnect.
Is it possible to configure the VPN from A -> B -> C, such that it won't boot my vendor off the RDP into B?
Of course, the easy answer is to enable direct VPN from A to C, but as I said, this cannot happen. I can't go into why, but it's not an option for us.
Posts
You'll need to change some settings to allow the VPN client on B to talk to A while the tunnel to C is up. Check the docs for "split tunneling". Usually the VPN host (C here) controls the client settings that would allow split tunneling.
Note that this would possibly have made their network security people crap their pants if they had been aware of it, since it would theoretically have been possible for malicious traffic to go from the Internet through my PC, into the VM and then through the VPN tunnel to the secure network. It's a pretty far-fetched scenario though since it would require that the malicious code actually be able to compromise the virtualization software itself. Said malicious code wouldn't be able to use the virtual network interfaces the VM software sets up, because those get locked down by the VPN client just like any other network interface. I felt it was reasonably secure, personally, but I also felt it was in my best interests to not mention my clever workaround to the people who owned the network I was using.
I'm thinking the best and most secure overall solution will be to have all my clients set up LAN to LAN VPN (i.e. hardware VPN) to network B (My Cisco PIX-501), and then I can allow my vendor to use software to VPN into my network...
So,
B -> C is hardware LAN to LAN
A -> B is software client based VPN
Now remember, even though you are joining yours and your clients networks via VPN, you can still configure your firewall to block anything except whatever services you want to transit the Site to Site VPN corridor.
From a single instance of an OS (WinXP 32bit as standard for most) it is incredibly finicky.
As someone else noted above, you need to have split tunneling enabled on both VPN connections, if you do not, it will either break the other VPN connection or simply not allow it to connect in the first place. The only way this would not be the case is if the second VPN is available through the first VPN:
PC connected to VPN A- company A VPN server - Internet -Company B VPN server
The above would be the path company B's VPN would need to traverse in order to connect... most companies would rather chew off their own arm than allow that.
Now, assuming that both A nd B's VPN configurations allow for split tunnel.... you would still have potential compatability issues. Either VPN could "bump" your network connection enough in the process to cause the first VPN to disconnect. You can also have issues where VPN software from one vendor just doesn't like that from another. Cisco and Nortel VPN software used to kill each other all the time, up to and including BSOD's. They have gotten better, but I still hear mixed reports about success.
And lastly, you could have resource conflicts if VPN a and VPN b have the same IP's used. IE: company A hands out 192.168.1.x VPN Ip's and so does company B. If you try and reach an address... which path will it take? And is that the right one?
It's just a logistical nightmare to work with, which is why it is almost never supported.