I have used VPN's from the vmclients in vmplayer, vmserver and vmworkstation with no problems, both "road warrior" and net2net.
If you're doing your own thing net2net is the easiest for multiple remote clients but there are security issues, especially if you have multiple physical NIC's but also even if you have only one NIC and have not properly firewalled/configured the host and all running vclients having inet access.
Most company VPN's are set up as "Road Warrior", meaning only a single address will be routed from the remote client, so the advice to use routing on the VPN remote client won't work, NAT routing may work, proxy definitely will.
Setting aside the specific routing restrictions of RW VPNs, there are many ways to configure your routing to accomplish host traffic thru a guest.
The recommendation I would make to a customer request for this would be to use transparent bridging on the host - No ip address assigned to the physical NIC.
Bridge eth0 to vmnet0 - this allow a vclient(s) that has a vNIC assigned to vmnet0 (bridged) to access the inet, get DHCP addresses from your DSL router, etc. I'll refer to this as your vGateway.
Add another vNIC (vmnet1 - host only) to the vGateway.
On the Host you should have NO address assigned to the physical NIC and a reserved address of 192.168.0.1 on vmnet1 (or whatever internal net you auto-assigned or manually assigned during vmware-config.pl)
Now try a ping test to verify the host can talk to the vGateway over vmnet1. Now assign the address of the vGateway as the default gateway for the host. Now try a ping test to the internet.
The host is now routing all traffic thru the vGateway. Additionally any vclient with a vNIC assigned to vmnet1 will be able to access the internet thru the vGateway. Any vclient needing access when vGateway is broken or down can be assigned to vmnet0 (bridge) to access inet directly.
If using a proxy you should now be able to bring up the VPN on the client and access over the VPN from the physical host.
If not using a proxy you will be able to send packets over the VPN but they may not get back because of filters/routing on the company side.
I never assign any IP's to the host, physical or vNIC's if using Virtualization. This is accomplished by only configuring a bridge to the external NIC during vmware-config.pl. Vmnet0-9 are always available to all vclients, network portion of vmware-config.pl is only for physical host vNICs. I prefer to not use VMware's DHCP server and assign and manage all addresses from the vGateway (I use a bsd or linux firewall for the vGateway, never windows, but you are trying to solve a slightly different problem). I use the Host as the server and vClients as the Firewall/Gateway and desktops. The host is used for backup's using vmount.pl, therefore there is never any network access to the host.
Same concept as above, just no ip addresses on the host, setup another "desktop" vclient on vmnet1 and set it's default gateway to your vGateway.
This way the only three methods of remote host exploit are:
Bridging exploit - Denial of service only so far.
Shared memory exploit - actively being tested and patched by VMware.
VMware channel exploit - actively being tested and patched by VMware. Can be disabled by not installing vmtools and config changes in .vmx, breaking time sync, copypaste and mouse focus.
Usually, I accept the risk of theoretical VMware exploits and use vmtools anyway, just be aware they may exist and apply patches (new versions) as soon as they are released. There are no publicly known exploit kits for vmware as of this date, in contrast to many available for windows and VMware programmers have been much more proactive in coding, testing and patching.
All my machines are setup this way and I use VPN's between vmnet1 nets on different machines so vclients from each machine can access each other, this way I can take my laptop to a public WIFI coffeshop or a clients company and never fear that my host will be comprimised, only the vclient(s). Depending on your use, VPN traffic can be higher performance than raw (compressed & filtered). Less slow network traffic traded off for some highspeed CPU time compressing/encrypting which can be offloaded by "server" class NIC's.
This is a great setup with USB WIFI, no drivers are installed on the host only in the vGateway. Now the Denial of service attack can't affect the host (if properly configured to not allow a vclient's cpu use to bring down the machine). And you can set the "coffeeshop" vclient to reset to snapshot on shutdown. You can do research surfing using windows (many bad web programmers still restrict websites to windows only) without having any fear of website trojan exploits, which are very common for windows. I would of still recommend that you always use anything but windows to surf, only use windows for sites that demand it and verify the site's prodigy first and never use windows for the host OS, only as a vclient if needed. VMware allows you to easily use linux, bsd, solaris or max osx regardless of the host system OS.
I've been writing up a detailed howto for this setup but keep getting distracted, hopefully it will be posted by xmas. (Fall is release time for Linux distro's).
*For those that might feel I'm windows bashing, I have purchased many versions of windows and dos from microsoft (dos, win,wfw,win98,nt,w2000,xphome,xpmedia,xppro,xp64,vista just to name a few). xp64, vista and continued ie bugs were the final straws.
*I do have a purchased license for VMware workstation but usually use vmserver because I rebuild often and rotate my machines and wish to remain license compliant. I recommend VMware workstation to every client for it's automatic inclusion of support.
Edit:
You stated your company requires a windows client to connect so I did not suggest you just VPN from linux or bsd. All VPN's I use are on linux or bsd on my end, with linux, bsd, windows, cisco, dsl routers, hardware firewalls, etc. on the other end. I've not yet run into a VPN that could not be connected to from linux, but only attempt this after speaking to your companies IT team, don't ignore company policy. Speaking of which, you should definetly let them know before you do this at all. The standard company policy restricts access to a single remote machine which should route all traffic thru the VPN, it should never allow direct internet traffic while routing only the company traffic over the VPN. You want to allow external access into your "vGateway" windows thus into the company and if incorrectly configured any vclient or host that is compromised could allow direct access into the company bypassing the companies firewalls from anywhere on the internet.
Message was edited by: Icantfindanametouse
