OpenVPN through an HTTP proxy: read the CONNECT reply first
A CONNECT proxy relays bytes, so both ends need TCP. Read 407, 403 and 503 before blaming certificates, and keep server verification on.
Point a VPN client at a corporate HTTP proxy and the first useful fact is that the proxy is not speaking the VPN's protocol. It opens a plain TCP connection to the address you named and then steps aside, leaving your client and the server to run their own exchange through that stream. Everything the client needs, from the transport type to the server's listener, has to match that arrangement. Two mismatches account for most of the failures: a UDP profile aimed at a CONNECT proxy, and a proxy reply mistaken for a VPN error.
What the proxy carries, and what it does not
The proxy is a transport hop. It does not become your browser proxy, it does not cache the sites you visit through the tunnel, and it does not see the inner traffic unless someone deliberately configured inspection. The tunnel it opens is opaque to it by design.
That also means the proxy cannot fix a server that has no matching listener. Permission to reach a destination and a service listening on that destination are separate facts, and only the first one belongs to the proxy administrator.
The carrier has to be TCP at both ends
A conventional CONNECT proxy only relays a byte stream, so the client must be using a stream transport. A client fragment for that case looks like this:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128The server side needs a real TCP listener on the port named in the remote line. Changing proto udp to proto tcp-client in a profile creates a client that expects a stream; it does not create the stream on the far side. If the same server also answers on UDP at that port, that is a different listener, not a second mode of the same one.
Where a separate TCP instance exists, its tunnel device, address pool and routing are resources of their own. Copying a working configuration and editing the transport word leaves those resources pointing at the original instance, which produces a connection that authenticates and then routes nothing.
Read the proxy reply before the VPN result
The client's first exchange is a request line naming the destination host and port. The reply to that line tells you whether a byte stream exists at all, and it arrives before any certificate or credential is checked:
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
A 200-class reply to CONNECT means the stream exists. It says nothing about whether the gateway certificate is trusted, whether the shared key matches, or whether the user account is valid. Those checks happen afterwards, inside the stream, and they fail with the client's own messages rather than an HTTP status line. Read the client log for the first OpenVPN event after the proxy handshake, not for the last line before the window closed.
Proxy credentials and VPN credentials are frequently different identities held by different teams. A 407 is not a bad password on the VPN account, and a rejected certificate is not a proxy permission problem.
What CONNECT does not expose
An explicit CONNECT tunnel is not interception. The proxy forwards bytes and does not terminate the VPN's TLS session, so the client's verification of the server certificate remains meaningful and should stay enabled. Turning verification off to get past a proxy is solving a different problem than the one you have.
Separate arrangements exist where an organisation terminates and inspects TLS deliberately. Those require their own trust configuration and their own policy decision, and they are not what a plain http-proxy line asks for.
The cost of TCP inside TCP
Carrying the tunnel over TCP keeps the outer stream ordered and retransmitted, and the inner traffic is usually TCP as well. The two recovery mechanisms do not coordinate, so a single lost segment can stall everything sharing that outer stream until it is retransmitted. That is a real trade for compatibility, not a free upgrade.
Use the proxy path when the network leaves you no alternative, and prefer a direct UDP path where policy allows it. Either way, confirm the same proxy, destination and profile reach the next stage after a change; a browser loading a page at that address exercises a different protocol and proves nothing about the tunnel.