I didn't want to hijack the other VPN thread for this purpose, so here
is a new thread. Anyone know much about how Juniper SSL-VPN networks
work?

Curious,
--patrick

[ message continues ]

It's a java based client that's run on the "client-side" and forwards
specified packets through a tunnel interface. It's not that different
from OpenVPN.

[ message continues ]

ahhh... Do you know if there are any open-source clients that are able
to connect through their service? I'm unable to google any specifics
on what "protocol" they use, or rather what their java app does after
it is launched. Is it safe to assume it is a closed and proprietary
solution?

I am hoping some clever person has figured out how to roll her own
equivalent of their java app using openssl/s_client or similar.

Thanks,
--patrick

[ message continues ]

Not as far as I know. To be honest, I've not researched it, but I know

I doubt it.

[ message continues ]

"Write Once - Run Anywhere", eh?
<Grinning, running and ducking!>


*** NOTE *** Please DO NOT CC me. I <am> subscribed to the list.
Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou.

Rod/
---
This life is not the real thing.
It is not even in Beta.
If it was, then OpenBSD would already have a man page for it.

[ message continues ]

Although I agree with that sentiment, I suspect the differences are to
account for how each OS handles things such as
/etc/{resolv.conf,hosts}, setting up interfaces, and other such
peculiarities that, as you can imagine, would, and do, vary from OS to
OS.

--patrick

[ message continues ]

The company i work for uses it. Its not that different from mature
ipsec vpn's - ssl is simply how the encryption is handled. The client
is configured by the central admin to enforce whatever policy is
requested (ours checks to make sure you run an acceptable host based
AV and firewall, blocks any post-connect changes to routing table,
allows split tunnelling only to the local subnet, etc). There is no
rolling your own client with ours, but it would be possible if the
admin of the VPN was very lenient (you can lock it down to only allow
certain versions of the client software etc or leave it wide open and
if it were wide open you could probably write something to fool it.

HOwever, no administrator should allow users to access a vpn (no
matter what flavor) using anything besides approved software since
that is the only way they have of being sure their policies are being
followed.

[ message continues ]

This is good info. So, if I understood what you are saying, assuming
the leniency you mentioned, the admin of the VPN, again assuming this
is someone in employment of my employer, would have enough knowledge
to share with me, about what the client they deploy "does" (the
required "handshaking", etc), to help implement my own client?

My fear is the folks in charge of this new VPN solution my employer is
rolling out, may not know about the specifics needed. But, based on
your comments they may.

Thanks for your post!
--patrick

[ message continues ]

That would be a rather optimistic assumption. They may be able to
configure the VPN endpoint to accept connections even by older versions
or somesuch, but that's a far stretch from writing your own
implementation.

As with most proprietary stuff, making it work may require
reverse-engineering everything. As with most proprietary stuff, this
sucks.

		Joachim

[ message continues ]

Since we are already off topic I'd like to point out something.

You should ask your corporate types if they support you as a user
connecting to the SSL box from your OpenBSD system.

Where I work, we have hardware / software requirements for remote
access.  Trying to "workaround" the system is not only not supported
but actually looked at as a violation of corporate policy.

my US$.02 worth

diana

[ message continues ]

Definition of "support" used in above context is highly vague. To my
new IT department "support" potentially translates to "we will hand
hold you if things don't work" or "we'll send someone to your office
to make sure your mouse cable is properly connected to your PC" or
something along those lines. Essentially, they would say we do not
support any OSes other than Windows NT and 2000 and two flavors of
Linux distros. Meaning when you call the "help desk" and say to them I
can't print to the printer down the hall, they will bring up a script,
off of which they'll read you instructions, based on the "supported"
OS you are using, how to configure the printer click-by-click.

Therefore, I'm not certain asking them whether or not they "support
... a user connecting to the SSL box from ... [a] system" not on their

Note, I'm not trying to "workaround" anything other than I refuse to
run a closed source application on my private system. Further, note,
my interest in accessing my employer's systems remotely is only to
benefit my employer -- I get no joy out of spending my personal time
working on things I work on when I'm on my employer's clock.

I hear you about "corporate policy". Depending on what business said
employer is involved in, that statement may or may not be reasonable.
Braindead policies, much like unconstitutional laws, must be
repealed/changed, ignored and/or rendered irrelevant.

--patrick

[ message continues ]

My daytime place of employment could care less if I do something
to benefit the employer with my personally owned equipment.  I suspect

Or you could find another employer since fighting "braindead policies"
often amounts to tilting at windmills.  If you get no joy out of
spending personal time doing something to benefit the employer 
then why do it?

When my current daytime place of employment starting throwing up more
and more roadblocks for remote access several years ago I quit doing
any off premise work for them.

diana

[ message continues ]

Any question starting like that is going to get answered quickly "NO!"
by PHBs.  Ask if they support SSL connections.  That will tell you if
they are trying for 'security' but simply unable to, or if they have an
axe to grind and are using the VPN for a non-technical agenda.
This should be about standards, not some brain-dead push to sell
boondoggles, regardless of whose cousin's shop is the reseller.

Also, speaking of brain-dead.  Avoid the term "support" until you are
clear about how they define it.  A lot of places have several tiers of
"support" ranging from having to be local experts on a tool to only
being able to install the package and say "you're now on your own"

If there is difficulty, arrange a pilot with OpenVPN on OpenBSD and run
a few use cases, gather a few metrics (ignoring previous thread on
metrics).  You can show increased "security" and, more importantly, savings.

/Lars

[ message continues ]

Since I contributed to an Off Topic thread to become even more off topic
I'll continue.

I don't know about you but I work for my employer, they don't work for
me.  If senior management gets marketed to by a vendor that could care
less about standards, let's see, Microsoft, Cisco, Juniper, IBM and on
and on, then decides to purchase and implement one of these vendors
solutions I'll implement it.  If I don't like it I can change jobs, I
don't take time to piss and moan about stupid management decisions.

My day time place of employment has Juniper SA boxes, personally I
think they are bizarre to say the least.  I would never subject one of
my personal systems to connecting to that network.

You aren't going to convince corporate types how great OpenVPN is on
OpenBSD.  The sad thing is US management blames SOX for decisions to
not use Open Source software, they need a liability trail, which
buying from a commercial entity provides.

I'm putting my soap box away for the day.

diana


[ message continues ]

They have an obligation to see that you have the tools to get your job

Not if you are doing your job competently.  If nothing else you're
supposed to ensure that your employer can meet its goals and, unless
they are simply existing to be a customer, then that means some
efficiency.

On the non-technical side, you're supposed to keep the boss looking good
and prevent flops.  Bad technology makes failure unavoidable.  Good



That comes down to, among other things, a deficiency of whiskey,
hookers, and blow from OpenBSD -- at least down here in userspace --
often referred to as Most Valued Partner Seminars.

It is possible you have managers that know nothing or care nothing about
their jobs. It is also possible that a quick hands-on demo can be done.
 Most managers have the imagination of a dried gnat.  You have to show
them.  However, once you have something to show, then you can bring in

Yeah and the sun was in their eyes, or there  was a cross wind, etc.
Open standards are not just an integral part of the buzzword computer
security, e.g.
	http://www.dwheeler.com/essays/open-standards-security.pdf
it is a prerequisite to 'staying upstream' or just plain keeping options
open and making money.+

-Lars

[ message continues ]

No they don't. Not on this continent anyway. They have an obligation
to a) make money and/or b) satisfy legal requirements. They have the
same inability to think about and make reasoned decisions on
everything that most humans have.

Sometimes that means they decide to trust you and accept your
decisions. Sometimes that means they decide to run with the herd

Ah, but they don't have to run faster than the bear. They just have
to run faster than YOU. Thus lowest common denominator technology
works fine and they will assume the magic pixie dust of their

If you don't think avoiding pissing and moaning is a proactive
approach you really need to get out into the 'real' world of
interacting with management more. True, drinking heavily is more

Even better, don't tell them anything (since they don't care) just
do it. That way you can try many different job opportunities during
your career. :-).

.... Ken

[ message continues ]

On Tue, Sep 15, 2009 at 3:01 PM, Joachim Schipper

You are right. I'm making some basic assumptions here. Namely, I am
assuming Juniper's client isn't doing anything fancy with packets read
locally before sending it over the SSL connection to the other

I hear you.

--patrick

[ message continues ]

nope

[ message continues ]

What do you want to know, besides their WebUI sucks?

diana

[ message continues ]