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]
