JP Vossen on 24 Jan 2009 12:40:17 -0800

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] VPN issues

 > Date: Sat, 24 Jan 2009 12:26:06 -0500
 > From: Robert Spangler <>
 > [...] In my opinion the proper way would be to VPN into a VPN Server
 > and then from there go to the other server and/or services within the
 > company network. As long as you are connected to the company using VPN
 > your box should not be allowed to talk with anything but the company
 > and access the Internet through the companies POA for security
 > reasons.

As a Certified Paranoid Security Geek, I agree.  As an end-user who is 
stuck using both types at different times, I disagree.

"Back-hauling" all traffic over the VPN to corporate is more secure, 
more controllable, and more logable.  But it's harder to set up well, 
terribly inefficient, and often painfully slow.  More to my and Michael 
Leone's point, it disallows local LAN printers and even more importantly 
local file shares!!!

That last one is a deal-breaker for me.  Of the 3 totally different VPNs 
I need to use for work (don't ask--really), two do not allow 
split-tunnels.  Since I need a Windows machine for work-stuff, and since 
I do not trust Windows with actual data, all my files (including Outlook 
.PST files, which is arguably insane) are on my "H:" drive on my Debian 
Etch Samba server.  So lack of split-tunneling is--problematic--for me, 
to the point that I built an XP VM that literally does nothing but act 
as a VPN client when I'm forced to use either of the non-split-tunnel 
VPNs.  That sucks.

Split-tunneling uses routing and other tricks to allow both "local" 
(which may include Internet) and VPN traffic.  It's arguably less secure 
in many ways, including potentially allowing "back-door" access in 
behind the corporate firewall [1].  This allows the use of local LAN and 
other resources without the inefficiency and extra latency (but also 
without the control) of back-hauling.  The routing will work as long as 
the local and remote LANs are different subnets.  That's one reason not 
to use the default subnets on all your network gadgets; using the 
defaults vastly increases the chances of collisions.

But it gets tricky with DNS.  even though you can have more than 1 DNS 
server, you really only use 1 at a time, unless it fails.  So if you use 
your local one it won't know about your remote stuff, or vice versa.  I 
typically use the remote DNS and my hosts file for local stuff.  That's 
tedious, but it works.  You can also fake your local DNS into pretending 
to be authoritative for the remote domain, but then it'll always be 
getting out of date.

 > If this is how you are doing things then then the firewall most likely
 > isn't allowing connection from the VPN to the Internet. Talk with your
 > network support to get this setup properly for you.

Ummm, I think Art *is* network support.  And the FW admin.  And the 
server admin.  I might be wrong though.


[1] I'm a lot more worried about the windows laptops that come back into 
the office Monday morning after being directly connected to the Internet 
all weekend than I am about "back-door" access behind the FW via 
mis-configured split-tunneled machines.
JP Vossen, CISSP            |:::======|
My Account, My Opinions     |=========|
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.
Philadelphia Linux Users Group         --
Announcements -
General Discussion  --