I've tried the connection with or without proxy, as long as the port of
server is 80 or 443, the NetApp NetCache will broke the connection after the
TCP connection established and client sent 1 packet.
I think it's because the first packet sent by client is not a TLSv1 CLIENT
HELLO Message( I can't parse it with ethereal ).

I've tried other SSL VPN software, it worked ,the only difference between
the other SSL VPN is the TLS handshake process.
So , again ,can we make the TLS handshake standard compatible.

On Dec 18, 2007 3:30 PM, Ross Cameron <ross.came...@linuxpro.co.za> wrote:

> On Dec 17, 2007 1:53 AM, dingchengyin 45702 <dingcheng...@huawei.com>
> wrote:
> > Hey,
> >     I think you all have noticed that the TLS handshake procedure of
> openvpn
> > client with server is different with the standard OpenSSL TLSv1
> handshake
> > procedure that with normal SSL/TLS browser with server.
> >     Since I'm using open in a HTTP Proxy + NetApp NetCache network. The
> > NetCache act as a transparent proxy, If I set my Openvpn server's listen
> > port to TCP 443 or port 80, then the client cannot connect to the server
> ,
> > after the first packet sent to server, the NetCache disconnect the  TCP
> > connection. This problem will not appear when I set the server listen on
> > other ports like 1194.
> >     This shouldn't be a big problem while I can connect to Internet, but
> > when I work in a Private network that only can go out though a HTTP
> Proxy,
> > then there are problems: the 80/443 port are the only two ports that
> allowed
> > to pass the filter of the proxy, while the NetCache will interrupt me
> from
> > connect to the server.
> >    Can we make the TLSv1 connection initialization process the same as
> the
> > OpenSSL library do, I mean there should be a Client Hello first ,then
> the
> > server reply with its certificate until it's encrypted on both
> direction.
> > Then we can send what ever data we want, right?
>
> Have you configured OpenVPN's client side to be aware of the proxy
> server or not?
> I've had a similar issue when I forgot to configure the clients to
>
> I stand corrected but I think OpenVPN changes its handshaking slightly
> when its configured to be used as a client /BEHIND/  a proxy server.
>      Assuming that it would pass through just any http(s) proxy when
> the server side port is 443/80 is flawed logic.
> Yes OpenVPN is a TLS/SSL VPN but this does not justify assuming that
> it works the same way as https.
>
> Try re-configuring you're client side to be aware of the proxying
> host, I'm sure that you will probably have a vastly improved
> experience.
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>

Reply via email to