On Tue, Sep 15, 2009 at 3:01 PM, Joachim Schipper <joac...@joachimschipper.nl> wrote: > On Tue, Sep 15, 2009 at 10:49:00AM -0700, patrick keshishian wrote: >> On Tue, Sep 15, 2009 at 5:59 AM, Henry Sieff <henry.si...@gmail.com> wrote: >> > On Mon, Sep 14, 2009 at 6:53 PM, patrick keshishian <pkesh...@gmail.com> >> > wrote: >> >> On Mon, Sep 14, 2009 at 5:44 PM, Johan Beisser <j...@caustic.org> wrote: >> >> > On Mon, Sep 14, 2009 at 5:39 PM, patrick keshishian >> >> > <pkesh...@gmail.com> wrote: >> >> >> (..) Anyone know (...) how Juniper SSL-VPN networks work? >> >> > It's a java based client that's run on the "client-side" and forwards >> >> > specified packets through a tunnel interface. >> >> ahhh... Do you know if there are any open-source clients (...)? > >> >> 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. >> > >> > 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. >> >> 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. > > 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.
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 end-point, and vice versa (aside from maybe cert handling). > As with most proprietary stuff, making it work may require > reverse-engineering everything. As with most proprietary stuff, this > sucks. I hear you. --patrick