TLS rides inside the control channel, not the whole tunnel

Finding the word TLS in a VPN description and concluding that a web proxy will understand the traffic is a common shortcut. Inside this protocol the peers exchange their own packets, and TLS runs as part of one channel within that exchange. The payload the user cares about travels in a different message format, which is why the two never line up with an ordinary HTTPS session.

The envelope comes first

Every tunnel packet starts with the protocol's own header: a message type, a key identifier and, over a byte-stream transport, a length prefix that marks where the packet ends. A reader that does not parse that envelope cannot know where the next field begins.

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

That sketch is a map rather than a byte table, because the exact fields depend on the message type, although the first octet always packs the opcode and the key identifier together. Guessing the message type from the port number is how decoders end up mislabelling what they see. The ordering is what matters for diagnosis: transport, then the protocol envelope, then one of two kinds of work. Read the envelope before you form any opinion about what follows it. A decoder that starts in the wrong place produces confident nonsense.

The reliability layer belongs to the protocol

Control messages need ordered, acknowledged delivery, and the protocol provides that itself with acknowledgements and retransmissions. An acknowledgement may arrive as its own message or travel with another control message, which makes traces look irregular to anyone expecting one clean exchange.

The benefit is that the TLS handshake gets a reliable carrier even when the outer transport is UDP. The cost is that a single datagram may contain only part of that conversation, so treating it as a standalone TLS record produces nonsense. Reassembly has to happen at the protocol layer. That is why a captured packet rarely looks like a complete handshake step.

Switching the outer transport to TCP does not remove this layer. Reliable transport means fewer retransmissions at the protocol level, not that the framing disappears or that the traffic becomes HTTP.

Data packets use a different format

Once the session exists, the useful payload arrives as data messages carrying inner IP packets or Ethernet frames. They are protected with their own keys and their own processing, and they are not TLS application records in any sense a TLS library would accept.

That separation is visible in configuration: the control channel and the data channel have separate cipher settings, so a log line naming one tells you nothing about the other. Reading a strong control cipher as proof of a strong data cipher is a common reporting error.

Keep a related misconception out of the explanation as well. TLS is not a public-key channel sitting beside a symmetric data channel, because TLS itself protects its records symmetrically once keys are established. The real distinction is role and packet format, not which kind of cryptography each side uses.

Why an HTTPS proxy cannot help

A proxy that terminates TLS expects a TLS record stream and then an application protocol inside it. This protocol's control channel is carried inside its own framing with a reliability layer around it, so a terminating proxy reads that framing as corrupt input.

A transparent forwarder that passes bytes or datagrams without interpreting them can work, provided it does not rewrite or reassemble the stream. The question to ask about any intermediary is whether it forwards the actual transport and framing, not whether it supports TLS somewhere. Ask that before you spend an evening on proxy rules. Most failures here are architectural rather than a missing setting.

Reading a trace correctly

Expect a control exchange first, then a much larger number of data messages, both sharing one transport. If the control phase completes and the data phase stalls, the fault concerns keys, routing or filtering of the data path rather than the handshake. Capture a few data messages and check whether they leave the client at all. That single observation splits the search in half.

Historical key-method descriptions in the protocol documentation do not imply that a given release still supports every old format. Check the version you run before building an expectation on a paragraph that describes how things used to work.