On 20101014 22:32 , Dan Brisson wrote:
> Bryan is correct that security best practices dictate not using split
> tunneling.

True enough, although I think it's wise to regularly revisit best
practices in security and update them to match current threats. (Without
opening up old exposures, of course.)

> Were it enabled, whenever a user VPNed into UVM, they
> would effectively be creating a bridge between the Internet and the
> internal UVM network...not good.

SVC is basically owning local routing on the client box; is it possible
to have it also disable packet forwarding, too? That would seem to
mitigate the above concern. (Unless you really mean it'd be bridging at
Layer 2. But then, I'd expect there to be some equivalent control point.)


On 20101015 10:39 , Marc Farnum Rendino wrote:
> And it seems to me that the potential increase in risk (of allowing
> split-tunneling) is minor, since the "horse is already out of the barn"
> so to speak, in that the security of the remote machines connecting in
> to the VPN is an unknown. And that's pretty much the same as the vast
> majority of machines on campus too.

Marc makes a fine point: Without meaningfully securing the endpoint,
we're only doing half the job. (Maybe less.)

Forcing remote clients to access the Internet through UVM's pipes means
that traffic is subject to UVM's border protections, though. That has
its advantages, in that it gives us decent visibility into the outward
symptoms of compromised endpoints -- outbound spam, data exfiltration,
botnet traffic, etc. At least while they're connected to the VPN...

This certainly increases costs, if not in terms of saddling users with
perceived impediments to productivity, then at least in bandwidth.


On 20101015 10:54 , Rama Kocherlakota wrote:
> Could we enable LAN access without enabling true split tunneling, as >
in this document:
>
>
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080702992.shtml

As long as packet forwarding can be disabled on the client (as above),
that's a decent, balanced solution.

I note (since it says "Note" ;-)) that, "When the VPN Client is
connected and configured for local LAN access, you cannot print or
browse by name on the local LAN. However, you can browse or print by IP
address." I'm presuming that means SVC's ACL magic isn't allowing the
broadcast/multicast traffic frequently used in local service discovery
and name resolution. That seems like it would be burdensome for those
constituents less-inclined to muck with their [lm]hosts files or run
local DNS services.


On 20101015 11:09 , Rama Kocherlakota wrote:
> I think the point here is that only machines on the user's LAN would
> be included - of course, even that is dicey since your LAN could be
> everyone in the airport departure lounge with you.

Again, if packet forwarding can be disabled on the client endpoint, this
is mitigated to a large extent. Unless, of course, you're sitting in the
airport lounge and running a VNC/RDP server on your laptop. Frankly,
though, that has the potential to be risky whether you happen to be
connected to the VPN at the time or not.


$0.02,

-sth

--
Sam Hooker | [log in to unmask]
Systems Architecture and Administration
Enterprise Technology Services
The University of Vermont