On Nov 4, 2010, at 9:13 AM, Les Mikesell <lesmikesell at gmail.com> wrote: > On 11/4/10 7:15 AM, Ross Walker wrote: >> >> >> If the client PC was set up in a split pipe setup it would be like running your corporate LAN with either no firewall or a consumer level firewall product with questionable administration. > > Things really aren't that simple, though. The big risk is not so much that an > outside source will be able to route directly through the connection because > most remote endpoints would be behind NAT, have an OS level firewall, and not be > configured for routing anyway. The more likely scenario is that the remote is > corrupted by some sort of trojan/virus malware which can make its own outbound > connectons or collect data to transmit later - and the problem is that this can > occur at any time prior to the vpn connection. It also isn't limited to vpns - > the same thing can happen when laptops are connected to the LAN or if you insert > any removable media, execute email attachments, browser plugins, etc., etc. And > browser plugins can even subvert what you are doing over ssl. You probably > permit outbound https connections and there's not much you can do to monitor them. Yes the malware threat is another big reason VPNs give me pause. >> You can filter within the VPN which protocols are passed but then at this point wouldn't it be better to do this at the firewall anyways? > > How much can you filter once all your connections are using ssl? And of course > you are still assuming that the bad guys are on the other side of your firewall > when statistics show otherwise. Well I'm only thinking perimeter at the moment, internal threats are a whole other can of worms and need to be handled differently. As for the SSL part, you can monitor traffic over it in a couple of ways. For internal services being served out you can have the SSL connection terminate at the gateway and the gateway establish an internal SSL connection to the service. For internal clients connecting to external services I have used SSL inspectors, these basically initiate an SSL connection to the destination, take the certificate, generate a per-destination itself and pass that to the client, basically acting as a man in the middle, as long as the gateway/inspector is a trusted intermediate CA and the subject is preserved then the client doesn't have a problem with it. -Ross