A tunnel didn't carry TLS

Code: egress.not_tls

What happened

A tunnel that must carry TLS didn’t, so the proxy closed it.

Awake sends no text for this: your tool prints its own error.

Why Awake does this

Every request a box sends leaves through the Egress Proxy, outside the box, which allows only what your org’s policy names and refuses the rest. The Egress Proxy says more.

What you can do

Use TLS to this destination, such as https.

Your tool prints its own error, since the proxy closes the tunnel before any answer. A tunnel to port 443 must start with TLS that names its host, as https does. On another port your org lists for the host, such as port 22 for git over SSH, a tunnel may carry another protocol where your org’s open egress setting is open, its default, unless your box’s posture is Offline.

What your admin can do

An Org admin lists a host on another port in Admin → Policies → Destinations, tunneled, such as github.com on port 22 for git over SSH. Where your org’s open egress setting is strict, every tunnel must carry TLS. The console doesn’t show that setting yet, so for now an Org admin changes it through Awake’s API.

For agents

Tell the person what was refused and why, with this code, and don’t retry in a loop. Don’t try another host, encoding or route to get around a control.

Where Awake records it

The Egress Proxy records each refusal, never the request’s data. Org admins and security auditors read the records in the Audit log.

A tunnel opened under a wildcard destination, such as *.example.com, is closed the same way, and recorded with this code, when its TLS names a host your org rules on its own: one of its exceptions, or a host it lists as a destination of its own.

egress.sni_mismatch: A tunnel’s TLS named another host
egress.plain_http: Plain HTTP was refused
egress.exception: Your org’s exceptions refuse this host

Still stuck

Ask your Awake admin. Give them the code, egress.not_tls, and when it happened.