How do I access my local network when on a VPN?
Discussion
zumbruk said:Sneaky, but won't quite solve the problem, unless I'm missing something. The VPN will still prevent the virtual machine from accessing the local network, so while the host PC will be able to print, the virtual one won't.
An easy way round this is to run the session that's connected to work in a virtual machine of some kind (either the free VMWare one, or MS's one).
You could always print to file, then copy the file to the PC and print off. Or print anyway and disconnect at intervals to allow your network printer to spool up. Or set up your printer as an internet printer? That's always handy anyway, when you're away from base you can sent printouts to your network printer from whereever. Print to a PDF file, and print that out when offline?
Here's the irony. Network Admins pretty much tick the "no local network access" box be default in the name of security. They also normally insist you have AntiVirus software loaded. My antivirus is a network edition, served from my local network. When I connect to corporate clients through VPN they disconnect my PC from its virus signature updates, and I can be connected all day. I normally update virus signatures hourly, but if their VPN settings are preventing signature updates, and a new virus gets into their network through my PC because it couldn't update signatures, who gets the blame?
If you're using a standard VPN client then just turn off the default gateway option. It defaults to 'on' for dialup connections which means that the dialup connection becomes the default outgoing route for your machine. If you turn it 'off' then only traffic that is specifically addressed to machines on the VPN will go over the VPN. This solves the problem.
GreenV8S said:Unfortunately most corporate will be using something slightly more "robust" than the default XP VPN client. Cisco VPN is very common, and this just isn't an option. I've even tried editing the .pcf file to add the EnableLocalLAN=1 option, but no joy.
If you're using a standard VPN client then just turn off the default gateway option. It defaults to 'on' for dialup connections which means that the dialup connection becomes the default outgoing route for your machine. If you turn it 'off' then only traffic that is specifically addressed to machines on the VPN will go over the VPN. This solves the problem.
GreenV8S said:
If you're using a standard VPN client then just turn off the default gateway option. It defaults to 'on' for dialup connections which means that the dialup connection becomes the default outgoing route for your machine. If you turn it 'off' then only traffic that is specifically addressed to machines on the VPN will go over the VPN. This solves the problem.
That only solves the problem of using local internet access as it changes the default gateway back to your own. He would still be able to access local (own subnet) network even with the default gateway set to the remote end. I'm guessing he's got something like the cisco client on and the policy is set at the remote firewall to block local net access
victormeldrew said:
GreenV8S said:Unfortunately most corporate will be using something slightly more "robust" than the default XP VPN client. Cisco VPN is very common, and this just isn't an option. I've even tried editing the .pcf file to add the EnableLocalLAN=1 option, but no joy.
If you're using a standard VPN client then just turn off the default gateway option. It defaults to 'on' for dialup connections which means that the dialup connection becomes the default outgoing route for your machine. If you turn it 'off' then only traffic that is specifically addressed to machines on the VPN will go over the VPN. This solves the problem.
The "local access" option in the Cisco IPSec VPN stuff is all driven from the server end. There's no way you can circumvent it at the client end (other than doing some seriously deep magic on the client).
zumbruk said:I thought that, but I stumbled across the .pcf file and option therein, so the hacker in me thought "why not?"!
victormeldrew said:
GreenV8S said:Unfortunately most corporate will be using something slightly more "robust" than the default XP VPN client. Cisco VPN is very common, and this just isn't an option. I've even tried editing the .pcf file to add the EnableLocalLAN=1 option, but no joy.
If you're using a standard VPN client then just turn off the default gateway option. It defaults to 'on' for dialup connections which means that the dialup connection becomes the default outgoing route for your machine. If you turn it 'off' then only traffic that is specifically addressed to machines on the VPN will go over the VPN. This solves the problem.
The "local access" option in the Cisco IPSec VPN stuff is all driven from the server end. There's no way you can circumvent it at the client end (other than doing some seriously deep magic on the client).
Seems silly to have a config option that does nothing. Still - deep magic eh? Don't suppose the incantations could find their way by email?
victormeldrew said:
zumbruk said:
An easy way round this is to run the session that's connected to work in a virtual machine of some kind (either the free VMWare one, or MS's one).
Sneaky, but won't quite solve the problem, unless I'm missing something. The VPN will still prevent the virtual machine from accessing the local network, so while the host PC will be able to print, the virtual one won't.
Sadly correct.
victormeldrew said:
but if their VPN settings are preventing signature updates, and a new virus gets into their network through my PC because it couldn't update signatures, who gets the blame?
Oh, that one's simple. You do.
Luckily I don't have to use anything special at the client side. Does the Cisco IPSec take over as the default route using the normal routing table manipulation, or is it doing something more fundamental? I can't see why there would be any need for the VPN client to inhibit the other interfaces, but maybe there's something I'm missing. If it's just as result of the routing changes then you could overcome it by changing the routing configuration yourself? (In fact that's how it used to be done here until I stumbled across the default gateway option ...)
You know I never actually checked but it does plant something in the IP stack so I suspect a simple manual route is not going to cut the mustard.
I had a client install go bad which meant no IP connectivity at all and I had to manually remove it as the uninstall wouldn't run. It messes with the windows login dialogue stuff too
I had a client install go bad which meant no IP connectivity at all and I had to manually remove it as the uninstall wouldn't run. It messes with the windows login dialogue stuff too
yeah but if I had something in the stack that sees all traffic and I had designed an option on my firewall server that banned local traffic I would just make my stack plugin conveniently lose all local ip packets down the nearest dev/null otherwise some smart alec will manualy edit the routing table and bypass my security feature 

GreenV8S said:
Luckily I don't have to use anything special at the client side. Does the Cisco IPSec take over as the default route using the normal routing table manipulation, or is it doing something more fundamental?
I only have experience of running it on Solaris, but it screws with all your network connections at some fundamental level way below default routes. I hate it. And I specified it.
If you have two networking devices, connect to the local network only on one and use the other one to connect to the local network, then vpn in to your remote network.
I am guessing this would work, but have never had a need to try it. I don't enable the restriction on the VPN clients for my firewall.
Otherwise, I would go with the virtual machine workaround.
GreenV8s' suggestion would not work for the reasons cited earlier.
I am guessing this would work, but have never had a need to try it. I don't enable the restriction on the VPN clients for my firewall.
Otherwise, I would go with the virtual machine workaround.
GreenV8s' suggestion would not work for the reasons cited earlier.
orgasmicliving!! said:
If you have two networking devices, connect to the local network only on one and use the other one to connect to the local network, then vpn in to your remote network.
Doesn't work. The Cisco VPN client, if configured so to do, kills all the other network connections. And bloody irritating it is, too. Hell, I can't get the LANRover Shiva (aka Intel VPN) client to route over its VPN tunnel, even though it theoretically should be able to.
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff



