What a corporate firewall can and cannot see inside a VPN

The same laptop reaches the VPN from home and cannot connect from the office, so someone must be reading the traffic. Blocking and reading are separate powers, and only the second needs a spot on the path plus a certificate the client trusts. A middlebox that drops your handshake has learned nothing about what you would have sent. Deciding which of the two you face is the whole job.

Blocking and reading are different powers

A refusal is cheap and loud: the socket opens and nothing answers, or a reset arrives at once. None of that implies inspection, because no payload crossed the wire.

Reading needs an endpoint that ends the protection, proves itself with a certificate, and starts a fresh connection onward. That endpoint must sit in the path and be trusted by the client. A firewall that only forwards packets has neither position nor credential.

What the wrapper gives away for free

Every tunnel packet has an outside, and the outside must be routable. That means two addresses, a protocol, a port and a length, plus timing and volume. Any router already handles those fields, and a NAT rewrites the address and port to keep its mapping table consistent. The payload stays sealed, so the observation stops at the fact that a tunnel exists between two hosts.

A hostname is not among them. Sites leak through other doors, and the widest is DNS: if the laptop still asks the local resolver, the names appear in the clear.

Timing and volume deserve respect without being overstated. Bytes per minute can show a large transfer starting at 14:20; they cannot show which file moved. That is a real disclosure about behaviour, and a different category from reading content.

TLS interception needs a root you already trust

An inspecting appliance does not break TLS; it ends it. The client is answered by a certificate from a root the organisation owns, and a second connection goes to the real destination. The client accepts this because that root sits in its trust store, which is why a managed laptop shows no warning. Cryptography was never defeated; the endpoint was moved.

This is also why the arrangement leaves evidence. The issuer on the presented chain belongs to the organisation rather than a public CA, and a client can see that without special tooling. A chain ending at an internal root is the signature of interception, not a malfunction.

Why a VPN channel is not an HTTPS session

A VPN data channel gives an inspector no such foothold. IKEv2 and WireGuard run their own handshakes and key schedules, with no TLS to terminate, while OpenVPN borrows TLS for its control channel in a modified form before protecting data its own way. A proxy built for HTTPS does not recognise that session as something it can parse.

An appliance that cannot parse a session can still drop it. That is why VPN blocking usually looks like a timeout rather than a certificate warning, and why an exception changes nothing.

Checking it from your own machine

Start with the chain the site presents. Browser site details show the issuer, and the command line reports the same thing without the summary:

openssl s_client -connect example.com:443 -servername example.com

Then separate a refused handshake from filtered inner traffic with counters. Log the transport port ahead of any drop rule and read them after the attempt:

iptables -I OUTPUT 1 -p udp --dport 1194 -j LOG --log-prefix ovpn-out
iptables -vnL OUTPUT --line-numbers

No log line at the outer socket means the handshake never left, so the path is refusing the tunnel. A completed handshake with only some destinations failing means the tunnel works and policy inside it does not. Neither result required reading a byte of payload.

The reading that does happen sits at the edges: a split tunnel hands internal HTTPS to a corporate proxy, and an employer-owned concentrator exposes everything at egress. Whatever you find, do not disable certificate verification to force a connection, because that check is the only thing separating inspection from an attacker.