SSL VPN

Post by Michel Servaes
Does pfSense offer an alternative to the Juniper SSL VPN solutions ?

<rant>
It is unfortunate that Juniper seems to have somewhat subverted the
meaning of the phrase "SSL VPN". IMO, the nomenclature indicates a
VPN that uses SSL for its authentication and encryption as opposed to,
say, IKE and ESP. It has nothing to do with whether the technology is
browser-based or not. OpenVPN is a _very_ good SSL VPN implementation
that requires no GUI components whatsoever, even though there are good
GUI clients written for it.

Furthermore, the "clientless" VPN solutions reduce the operator's
control over the endpoints, degrading the overall security of the
system. Some solutions attempt mitigating controls, but you can't
change the fact that you're allowing rather arbitrarily secured
machines to utilize your resources. Of course, if you don't plan to
vet the systems clients will be using (when issuing certificates or
the like), that doesn't matter much.
</rant>

That said, pfSense does not offer what you are looking for. Your best
bet to implement precisely that would probably be to purchase a
solution like SSL Explorer (still cheaper than a Juniper) and run it
on a dedicated machine in a DMZ off of pfSense with limited access in
& out.

RB

Michel Servaes

2008-07-08 19:57:20 UTC

I totally agree with you, but you know what happens if an external IT
man enters your office, and tells your boss that a solution like Juniper
is better than anything else...
So I am going to use your comments to discourage this kind of use... I
still like to have control of what comes in, and what goes out.

I haven't enabled OpenVPN on my pfSense... I have no knowledge about
OpenVPN.
I only use IPSEC for endpoint to endpoint, and PPTP for mobile
solutions, or collegues who don't have an out-of-the box VPN capable
router at home.

Thank you for your response already ;)

Post by Michel Servaes
Does pfSense offer an alternative to the Juniper SSL VPN solutions ?

<rant>
It is unfortunate that Juniper seems to have somewhat subverted the
meaning of the phrase "SSL VPN". IMO, the nomenclature indicates a
VPN that uses SSL for its authentication and encryption as opposed to,
say, IKE and ESP. It has nothing to do with whether the technology is
browser-based or not. OpenVPN is a _very_ good SSL VPN implementation
that requires no GUI components whatsoever, even though there are good
GUI clients written for it.
Furthermore, the "clientless" VPN solutions reduce the operator's
control over the endpoints, degrading the overall security of the
system. Some solutions attempt mitigating controls, but you can't
change the fact that you're allowing rather arbitrarily secured
machines to utilize your resources. Of course, if you don't plan to
vet the systems clients will be using (when issuing certificates or
the like), that doesn't matter much.
</rant>
That said, pfSense does not offer what you are looking for. Your best
bet to implement precisely that would probably be to purchase a
solution like SSL Explorer (still cheaper than a Juniper) and run it
on a dedicated machine in a DMZ off of pfSense with limited access in
& out.
RB
---------------------------------------------------------------------

Fuchs, Martin

2008-07-08 21:42:40 UTC

Watchguard also has some "SSL-VPN" and I know the sales-man entering the boss' office...

But pfSense won...

We use OpenVPN cause the boss looks at the bucks it costs... and that was the argument :-)

Try OpenVPN on pfSense... you'll love it...

Only thing with WatchGuard: it uses SSL-VPN via browser... some kind like SSL-Explorer...

If your boss likes that, trya the SSL-Exploer Community edition...

Regards,

MArtin

-----Ursprüngliche Nachricht-----
Von: Michel Servaes [mailto:***@mcmc.be]
Gesendet: Dienstag, 8. Juli 2008 21:57
An: ***@pfsense.com
Betreff: Re: [pfSense Support] SSL VPN

I totally agree with you, but you know what happens if an external IT
man enters your office, and tells your boss that a solution like Juniper
is better than anything else...
So I am going to use your comments to discourage this kind of use... I
still like to have control of what comes in, and what goes out.

I haven't enabled OpenVPN on my pfSense... I have no knowledge about
OpenVPN.
I only use IPSEC for endpoint to endpoint, and PPTP for mobile
solutions, or collegues who don't have an out-of-the box VPN capable
router at home.

Thank you for your response already ;)

Post by Michel Servaes
Does pfSense offer an alternative to the Juniper SSL VPN solutions ?

<rant>
It is unfortunate that Juniper seems to have somewhat subverted the
meaning of the phrase "SSL VPN". IMO, the nomenclature indicates a
VPN that uses SSL for its authentication and encryption as opposed to,
say, IKE and ESP. It has nothing to do with whether the technology is
browser-based or not. OpenVPN is a _very_ good SSL VPN implementation
that requires no GUI components whatsoever, even though there are good
GUI clients written for it.
Furthermore, the "clientless" VPN solutions reduce the operator's
control over the endpoints, degrading the overall security of the
system. Some solutions attempt mitigating controls, but you can't
change the fact that you're allowing rather arbitrarily secured
machines to utilize your resources. Of course, if you don't plan to
vet the systems clients will be using (when issuing certificates or
the like), that doesn't matter much.
</rant>
That said, pfSense does not offer what you are looking for. Your best
bet to implement precisely that would probably be to purchase a
solution like SSL Explorer (still cheaper than a Juniper) and run it
on a dedicated machine in a DMZ off of pfSense with limited access in
& out.
RB
---------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: support-***@pfsense.com
For additional commands, e-mail: support-***@pfsense.com

Chris Buechler

2008-07-08 22:01:24 UTC

Post by Fuchs, Martin
Watchguard also has some "SSL-VPN" and I know the sales-man entering the boss' office...

Yeah, the "but this guy says XYZ is the best" argument is easily
countered with, well, that's what he's selling, what do you expect him
to say? That an open source solution with a total cost of thousands
of dollars/Euros/whatever less is an equally good solution and you
should use it instead of buying what he's selling? :) My guess is
such a salesman would quickly find himself unemployed.

Post by Fuchs, Martin
But pfSense won...
We use OpenVPN cause the boss looks at the bucks it costs... and that was the argument :-)

Yep. Juniper makes good products, but pfSense is equally suitable for
vastly less money in a lot of environments.

digger

2008-07-08 23:58:17 UTC

It would be great if there were a clientless SSL VPN product like
SSL-Explorer that used a java applet for the client side but had the
server written in something like C that would be far less resource
intensive on the server and would run on pfsense. Does anyone know of
such a beast?

Digger

Post by Fuchs, Martin
Watchguard also has some "SSL-VPN" and I know the sales-man entering the boss' office...
But pfSense won...
We use OpenVPN cause the boss looks at the bucks it costs... and that was the argument :-)
Try OpenVPN on pfSense... you'll love it...
Only thing with WatchGuard: it uses SSL-VPN via browser... some kind like SSL-Explorer...
If your boss likes that, trya the SSL-Exploer Community edition...
Regards,
MArtin
-----Ursprüngliche Nachricht-----
Gesendet: Dienstag, 8. Juli 2008 21:57
Betreff: Re: [pfSense Support] SSL VPN
I totally agree with you, but you know what happens if an external IT
man enters your office, and tells your boss that a solution like Juniper
is better than anything else...
So I am going to use your comments to discourage this kind of use... I
still like to have control of what comes in, and what goes out.
I haven't enabled OpenVPN on my pfSense... I have no knowledge about
OpenVPN.
I only use IPSEC for endpoint to endpoint, and PPTP for mobile
solutions, or collegues who don't have an out-of-the box VPN capable
router at home.
Thank you for your response already ;)

Post by Michel Servaes
Does pfSense offer an alternative to the Juniper SSL VPN solutions ?

<rant>
It is unfortunate that Juniper seems to have somewhat subverted the
meaning of the phrase "SSL VPN". IMO, the nomenclature indicates a
VPN that uses SSL for its authentication and encryption as opposed to,
say, IKE and ESP. It has nothing to do with whether the technology is
browser-based or not. OpenVPN is a _very_ good SSL VPN implementation
that requires no GUI components whatsoever, even though there are good
GUI clients written for it.
Furthermore, the "clientless" VPN solutions reduce the operator's
control over the endpoints, degrading the overall security of the
system. Some solutions attempt mitigating controls, but you can't
change the fact that you're allowing rather arbitrarily secured
machines to utilize your resources. Of course, if you don't plan to
vet the systems clients will be using (when issuing certificates or
the like), that doesn't matter much.
</rant>
That said, pfSense does not offer what you are looking for. Your best
bet to implement precisely that would probably be to purchase a
solution like SSL Explorer (still cheaper than a Juniper) and run it
on a dedicated machine in a DMZ off of pfSense with limited access in
& out.
RB
---------------------------------------------------------------------

---------------------------------------------------------------------

Matthew Grooms

2008-07-09 00:54:55 UTC

Post by digger
It would be great if there were a clientless SSL VPN product like
SSL-Explorer that used a java applet for the client side but had the
server written in something like C that would be far less resource
intensive on the server and would run on pfsense. Does anyone know of
such a beast?

The whole idea of clientless VPN is a complete marketing ploy. You can't
redirect traffic passing through the kernel from user land without
installing some sort of kernel mode driver and key management software
on a computer. Java is an application framework and it doesn't offer any
of this functionality natively. Sure, the key exchange and GUI parts may
run in java, but then you have a 15MB JRE dependency for 5MBs worth of
applications. How thin is that? When you read between the lines of the
marketing hype, companies usually mean easy web deployment of the client
software via a browser when they say 'clientless' solution. That doesn't
mean there isn't sophisticated client software involved.

One of the worst remote access implementations I have ever seen was a
clientless VPN product. It used java application components ( that only
worked right with certain JRE versions ) and installed a kernel mode
winsock redirector to capture traffic. I was horrified to discover that
some of what they did was accomplished by setting entries in the hosts
file as 127.0.0.1 ( yes ... really ) to force connections local. Believe
it or not, this was a rather expensive Juniper product with hefty client
license fees.

While SSL VPNs are becoming more and more popular, there is really no
standard for them to adhere. Sure, they use SSL but for what and how
effectively? You place the trust in the vendor to do the right thing and
hope for the best. This also means that there is almost no chance for
interoperability between SSL VPN product lines. Better for the vendor,
bad for the consumer. Tunneling traffic over TCP also has some severe
performance drawbacks. There is a reason why IP security protocols ( not
socket layer protocols ) are written in a connectionless fashion. They
have no business providing services like guaranteed messaging.

OpenVPN uses SSL for negotiation and key exchange. When securing user
traffic, it actually uses the IPsec ESP protocol ( w/NAT-T extensions ).
So calling it an SSL VPN solution is really a misnomer. Its really a
Hybrid solution and a very good product all around.

Luckily, there is also a standard for securing IP communications. Its
has widespread adoption, a huge installation base and inter-operates
well between vendor implementations. Its called IPsec.

-Matthew

Bill Marquette

2008-07-08 22:27:23 UTC

Post by Michel Servaes
Does pfSense offer an alternative to the Juniper SSL VPN solutions ?

<rant>

Post by RB
Furthermore, the "clientless" VPN solutions reduce the operator's
control over the endpoints, degrading the overall security of the
system. Some solutions attempt mitigating controls, but you can't
change the fact that you're allowing rather arbitrarily secured
machines to utilize your resources. Of course, if you don't plan to
vet the systems clients will be using (when issuing certificates or
the like), that doesn't matter much.
</rant>

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.

--Bill

2008-07-08 23:01:24 UTC

Post by Bill Marquette
With OpenVPN, you only have control of the client at time of install.

True; even further, you only have control of the credentials at the time of issue, as the client software is freely available and trivial to install. However, in the environments I come from that is viewed as an acceptable risk as rather iron-fisted control is exercised over the client machines from birth to death, effectively extending the chain of trust through OS installation. In this arena that doesn't prevent them from taking their credentials and using them on a rogue machine, but we deal with that in meatspace.

Post by Bill Marquette
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.

Absolutely - that's the "...attempt mitigating controls..." I glossed over. I don't think I'm up to arguing the validity of HIDS and NAC right now, but it's the same concept: the software that runs on the client can only report what the OS tells it. While we're there, I also cringe at the idea of giving a web browser sufficient access to the OS to try to sufficiently validate those items, particularly since so many of the solutions are IE-centric.

Post by Bill Marquette
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.

Appreciate the clarification. I think each solution has its place given proper analysis and control, but also that the "browser VPN" is one of those magic bullet solutions too many people think is going to save the world/heal cancer/free kevin.

RB

Bill Marquette

2008-07-09 00:39:40 UTC

Post by RB
Absolutely - that's the "...attempt mitigating controls..." I glossed over. I don't think I'm up to arguing the validity of HIDS and NAC right now, but it's the same concept: the software that runs on the client can only report what the OS tells it. While we're there, I also cringe at the idea of giving a web browser sufficient access to the OS to try to sufficiently validate those items, particularly since so many of the solutions are IE-centric.

No disagreement there. It's worth noting that to get a real VPN out
of the browser based solutions, instead of just a port forward here or
there, the user usually has to either have administrator level access
to the workstation (now why on earth would you do that in an
enterprise? :)) or have a shim (clientless? hah!) installed that
grants them this access.

Post by RB
Appreciate the clarification. I think each solution has its place given proper analysis and control, but also that the "browser VPN" is one of those magic bullet solutions too many people think is going to save the world/heal cancer/free kevin.

True. Each has it's merits and no "perfect" solution, is perfect for
all. But I digress...for "SSL VPN", we also have stunnel :)

--Bill

Chris Buechler

2008-07-08 23:06:20 UTC

Post by Bill Marquette
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.

Bill Marquette

2008-07-09 00:34:59 UTC

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

DLStrout

2008-07-09 01:32:03 UTC

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: bill.marquette-***@public.gmane.org
TO: support-***@public.gmane.org
DATE: 07-08-2008 8:34 pm
On Tue, Jul 8, 2008 at 6:06 PM, Chris Buechler

Post by Bill Marquette
With OpenVPN, you only have control of the

client at time of
install.

Post by Bill Marquette
With the "clientless" solutions from Juniper,

F5, et al, they
usually

Post by Bill Marquette
have the ability to check the security of the

environment they're

Post by Bill Marquette
running in, in some manner (antivirus running,

up to date
patches,

Post by Bill Marquette
firewall, etc). They can then grant or deny

access based on that

Post by Bill Marquette
security - with OpenVPN, if the credentials

are good, you get in.
I

Post by Bill Marquette
won't argue the points as to which is better,

or whether you
should

Post by Bill Marquette
even have remote access to your network, just

wanted to point out
some