Http/S proxy hijacking OpenVPN (aka Astaro SSL-VPN)

[DiePlage]

Whenever I try to establish an OpenVPN connection on port 443, it is intercepted by the https-proxy. This is to be expected. However the ssl handshake fails if the remote openvpn-server uses a self-signed certificate, I can see this in the https-proxy live-log:

httpproxy[3830]: [0xad331a10] ssl_log_errors (ssl.c:41) C: 3830:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:562:.
httpproxy[3830]: [0xb360c9c8] ssl_log_errors (ssl.c:41) C: 3830:error:140ED0E5:SSL routines:SSL23_PEEK:ssl handshake failure:s23_lib.c:165:

The OpenVPN-log shows:
Thu Feb 05 19:49:26 2009 Connection reset, restarting [-1]
Thu Feb 05 19:49:26 2009 TCP/UDP: Closing socket

For all I can see this is the expected behaviour as astaro can't authenticate the remote side.

I belive I could import all CA-certificates of the remote OpenVPN servers to solve this. This would mean a lot of work plus it can't be done be "ordinary" users.
I suppose that AFTER the OpenVPN-connection has been established, there is nothing being transferred that could be scanned by the webfilter anyway.
So, is there a way to exclude OpenVPN connections from being scanned? Or to put it in other words, is there a way for astaro to tell that this isn't a connection to a "real webserver"?

Thanks a lot for any clarification / hints!!

[svens]

Do you have added the OpenVPN remote peer added in the Transparent mode skip list? OpenVPN will probably not work over the proxy.

Cheers,

Sven.

[DiePlage]

Can astaro detect wich content type is being transmitted inside an established SSL tunnel?
If I remember correctly (and it's been a while), HTTPS is actually a HTTP connection UPON an established ssl tunnel.
I suppose the SSL-Proxy works something like this:
ASG captures the beginning of an ssl-handshake between a local peer an a server on the internet (or another lan). It then establishes a ssl-connection to that server and requests the captured url. At the same time it generates a ssl certificate signed by it's own CA faking the identity of the remote server, establishes a ssl connection with the requesting client and delivers the scanned content retrieved from the remote server.
Is this correct, so far?

With OpenVPN as it is preconfigured by astaro we have the problem that it also uses port tcp/443.
I understand that it is not possible to establish an openvpn connection with an enabled https-proxy in the middle as the certificates stored in the clients configuration would never match.

Now my question would be:

Is there a way to tell, whether the attempt to create a ssl tunnel was initiated by a webbrowser or something else?
I don't know how the handshake with a https-webserver really works, maybe the target url is being transferred at some point. Maybe there is a content-type header field or something alike. That could then be used to differentiate whether there it is http being tunneled or anything else.

I know that if you open port 443 outbound on your firewall you most likely DO NOT want people to use it for anything else than https, nevertheless it would be usefull if you COULD tell what it's being used for.