I've watched the stream all afternoon and just wanted to offer my .02 worth on the matter as we have a rather large multi-VPN deployment with a mix of solutioning to fit the appropriate needs.
Point I: I agree whole-heartedly that if you are in control of the workstations/laptops "abroad" and the users have NO administrative rights to install augment its OS/apps then OpenVPN is a great RWA (road warrior access) method and works flawlessly on pfSense. We have a couple of dedicated "VPN" servers (RWA and S2S) sitting in a DMZ off from another heavy edge pfSense box, that way we have the granularity of policy (rules) to pear down what is accessed and what is not when the RWA client is auth'd and has connectivity. We also have it taylored to S2S (site to site) VPN connectivity (both IPsec and OVPN) so that all traffic and routing are choked via policy rules within the edge pfSense and a backend (behind the edge pfSense) router w/ simple ACLs. All of this can be acomplished quite easily w/ pfSense and some time spent on the mail lists to see how to setup multiple OVPN and IPsec connectivity. Point II: For the "untrusted" client or "the ones you don't manage and admin" you might consider a RDP solution ... i.e., have the auth and establish to a very restrictive pfSense OVPN server {in a controlled DMZ} and then ONLY allow RDP to a trusted and hardened term-server for the apps they need inside your network. Point III: Ah yes, the SSL-VPN mis-conception ... well browser-based VPN is all of the rage and is certainly making justification of client based IPsec VPN a toughER sell. It has it's perts and it is without question a "easy-deploy" thus begging the question (like has been stated earlier in this stream) is the "end-point" to be trusted (and if not ... how do we mitigate)? Another deployment we have here for those VERY few I couldn't sell on either of the two previous solutions was to grab a "fairly" cheap Netgear SSL312 off the net and put it in yet another dedicated VLAN/DMZ/security-zone and allow those few that "had to have it" connect and then pare the access down with tried and true pfSense. You can also very easily with some older hardware ramp up a SSL-Explorer "community edition" (again ... as has been stated) and it should provide relatively the same "feel" for the end-user experience. Conclusion: I would vest in a decent and fairly robust "edge pfSense" (hardware) and then make that your point of CONTROL (not termination) for VPN access. IMHO, it is a safe bet that if you loose a VPN "server" someday (and you probably will) due to hack, mis-config, client compromise, etc.) then you'll still have your "main" firewall intact and helping in control and mitigation. Follow-on: All of the above is assuming you are "doing this VPN design" for a business. If we are talking SOHO then you can (and I have several such clients "outside" that are perfectly comfortable running the whole RWA and "edge" firewall on one box) ... pfSense is without question capable and ready for this task as well. As is the mantra out of the devs at pfSense ... home, SOHO, ROBO or enterprise ... pfSense can fit in all of these spaces very well and is rivited with features and accessories to meet just about any "ACCESS" task .. head-on! Again ... just my .02 worth. Regards, -- David L. Strout Engineering Systems Plus, LLC ----- Original Message ----- SUBJECT: Re: [pfSense Support] SSL VPN FROM:[EMAIL PROTECTED] TO:[EMAIL PROTECTED] DATE: 07-08-2008 8:34 pm On Tue, Jul 8, 2008 at 6:06 PM, Chris Buechler wrote: > On 7/8/08, Bill Marquette wrote: >> >> With OpenVPN, you only have control of the client at time of install. >> With the "clientless" solutions from Juniper, F5, et al, they usually >> have the ability to check the security of the environment they're >> running in, in some manner (antivirus running, up to date patches, >> firewall, etc). They can then grant or deny access based on that >> security - with OpenVPN, if the credentials are good, you get in. I >> won't argue the points as to which is better, or whether you should >> even have remote access to your network, just wanted to point out some >> missing information in your argument. >> > > Yeah none of the VPN options in pfSense currently offer any client > side policy enforcement (patches accepted). Whether or not that's a > concern depends on your environment. Personally, almost all the VPN > deployments I've seen that have this capability do not use it for > various reasons. It usually becomes a support nightmare when you allow personal workstations on your network. But it can easily be argued (to RB's points) that you shouldn't allow that in the first place. These solutions have a place, but it's usually mis-deployed to pretend to mitigate a security issue that is better solved with policy, education, and dollars spent giving your employees the tools they need to do their jobs instead of forcing them to use their own money to perform your work. --Bill --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]