One major problem I have is corporate IT policy (Oh, I'm not alone then? :) )

Specifically that if I'm off-site using a VPN connection, I cannot link to anything outside that VPN connection.

So my local printer at home is off-limits unless I disconnect - a simplistic example of the hampering. I've been pondering whether a VM machine (or two) could circumvent that by fooling the VPN connected session into thinking another VM session is on the corporate network when it's actually local.

Any ideas?

+2  A: 

I have tried this before, using VMware, and the issue I had was that the VPN software my company uses (Contivity) takes over the physical connection from a machine, and thus it did not help at all. Once I connect on the VM, all other connections to my network are disconnected. Quite annoying, though it is more secure, and that is what it is designed for...

Adam Lerman
+6  A: 

It's all about gateways - your VPN client must be routing all traffic through the VPN. Why not configure it so that it only sends relevant traffic through there?

(OpenVPN can be configured this way, YMMV).

Matthew Schinckel

Adam seems to have the news of doom - we're using Cisco VPN and it overrides the physical connection (or at least it's gateway settings, etc).

+1  A: 

I would suggest giving this a shot with Microsoft's Virtual PC. I have successfully setup the cisco vpn client inside of the virtual that did not affect the host machine. And yes, the vpn software is configured to override the default gateway on the system. Maybe this is a difference in functionality between vmware and virtual pc.


I do this very successfully with Cisco VPN running in Vista in Parallels in OS X. The VPN steals all networking within Vista, but networking at the OS X level is unaffected.

+1  A: 

I've done this with Cisco VPN in VirtualBox on both Windows and Linux. Works just fine. Go get it. It's open source and everything.


I've done this successfully in Windows XP running inside of Vmware workstation... Though, being an IT guy myself, we can disable the VPN client per machine, or run a pre-check to see if its running inside of a VM.

Sargun Dhillon

It became useful first to distinguish among different kinds of IP vpn based on the administrative relationships, not the technology, interconnecting the nodes. Once the relationships were defined, different technologies could be used, depending on requirements such as security and quality of service.


If you can run the VPN client in the guest OS inside the virtual machine, then you're golden. I've done that a number of times with a number of different VPN clients.

On the other hand, if for some reason you have to run the VPN client in your host OS then I believe you're out of luck. Most enterprise VPN clients are designed to be pretty thorough at preventing any processes (including the virtualization software) from bypassing the VPN restrictions.

The key is that you need to be running the VPN client in the guest OS. A VPN client in the guest OS will have no control over the host OS. A VPN client client running in the host OS will be able to affect the connectivity of any guest OS.

Bob McCormick
+2  A: 

I've seen this before when using Microsoft's VPN client. If you untick the option to route all traffic through the VPN you end up only being able to talk to the RAS server at the other end, and not the rest of the office network.

I solved this by modifying my routing table to route my office network traffic through the RAS server as a gateway, but to not route ALL my traffic into the VPN.

To see your current routing table, run the command

c:\\> route print               (Output edited to make clearer)

Interface List
 11 ...00 1f 3b 77 41 ab ...... Intel(R) Wireless WiFi Link 4965AGN
  8 ...00 1a 80 f6 67 81 ...... Generic Marvell Yukon Chipset based Etherne


IPv4 Route Table

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
     20         On-link    306         On-link    306         On-link    306         On-link    276         On-link    276         On-link    276         On-link    306         On-link    276         On-link    306         On-link    276

Persistent Routes:

Now, dial into your VPN connection and print out the route list again. you should see an additional interface and some routing added. You can then use the ADD option with the route command to correctly route your traffic.

There are some consequences to this approach. Often the IP addresses used in offices are not unique real internet IP addresses, but belong to the private range. However, your routing table cannot tell the difference between at home and at work. If you are using the same IP address range localy and at work this will not help.

Also, note you are working directly on your routing table. Get it wrong, and you may not be able to get to the internet to find the command to fix it!

I am not confident enough of the exact parameters to apply to ROUTE /ADD to be sure of getting it right so the only suggestion I am going to make is to take advantage of the fact that the routing change is not preserved over a reboot unless you use the -p parameter. only when you have fully tested it, make it fixed.

Two comments. 1. This is what I'd suggest as well, but I'd recommend putting it into a script. 2. A reboot should reset your routing table.
Can you give more details on how to do a route add for a particular interface?

Once one has a running VPN connection inside of a guest, is there any way to allow the host to use the VPN connection? I've tried bridge networking and ICS to no avail; I haven't tried setting up the guest as a proxy for the host yet, though.

The host is Win7 64-bit; the guest is WinXP 32-bit.