Why does the Edge gateway reject the upgrade with CNTL=0x15?
The Edge gateway sent a cleartext request to a listener that answered in TLS. In this installation both gateways ran 8.3. The connection failed first with TLS enabled, then failed with TLS disabled on both, which produced the error below. It came up only after TLS was enabled on both gateways and the certificate was approved:
Response code='400', error message='org.eclipse.jetty.websocket.api.exceptions.UpgradeException: org.eclipse.jetty.websocket.core.exception.UpgradeException: 400 Illegal character CNTL=0x15An outgoing Gateway Network connection is a WebSocket carried over HTTP or HTTPS and handled by Jetty on both ends. The outgoing gateway sends an HTTP GET with an Upgrade header and expects a status line that begins with HTTP/1.1 101. Byte 0x15 (decimal 21) is the TLS record type for an alert. A TLS listener that receives plaintext GET /... cannot parse it as a TLS record, so it returns an alert record and closes the socket. The Jetty client parser expects H as the first byte of the response. When it reads 0x15 instead, it reports an illegal control character and wraps the error as a 400 UpgradeException. The 400 is raised by the client's parser. No HTTP handler on the central gateway ever saw a valid request.
| First byte the parser sees | Meaning | Mismatch direction |
|---|---|---|
0x15 |
TLS alert record | Cleartext client connected to a TLS listener |
| TLS handshake record (ClientHello) | TLS client connected to a cleartext listener. The server's HTTP parser rejects it and the client reports a handshake failure. | |
(H) |
Valid HTTP status line | Protocols match. Any remaining failure is certificate, trust, or connection approval. |
Where along the path does the request stop?
Trace the connection from the side that initiates it. The Edge gateway owns the outgoing connection, so its settings define the host, port, and protocol.
| Hop | What travels | Failure signature |
|---|---|---|
| 1. Edge outgoing connection config | Target host, port, TLS flag | Wrong port or TLS flag produces a protocol mismatch at hop 3 |
| 2. IP/TCP path | SYN / SYN-ACK to the target port | Timeout or connection refused, with no HTTP error |
| 3. Central gateway listener | First application bytes |
CNTL=0x15 or when the two ends speak different protocols |
| 4. TLS handshake | Certificate exchange | Handshake or trust error |
| 5. HTTP upgrade | 101 Switching Protocols |
Genuine HTTP 4xx or 5xx from the server |
| 6. Gateway Network handshake | Connection and certificate approval | Connection stays pending or unapproved |
CNTL=0x15 places the fault between hops 3 and 4. TCP completed and bytes came back, so routing and the firewall are passing traffic. The bytes that came back were TLS.
How do you prove what the target port speaks?
Check the physical and transport layers first, then probe the protocol. Run these from the Edge host so the test follows the same path the gateway uses.
Compare two values: whether the port presents a certificate, and whether the Edge outgoing connection has TLS enabled. If they disagree, you have found the mismatch. If you changed the Gateway Network ports from their defaults, read the actual TLS and cleartext port numbers from the central gateway's Gateway Network settings and probe those ports.
TLS on both or cleartext on both: which should the link run?
A matched configuration works in either mode. A mixed configuration never works. This installation failed in cleartext because the outgoing connection still reached a port that answered in TLS.
| Criterion | A: TLS on both, target TLS port | B: Cleartext on both, target cleartext port | Mixed |
|---|---|---|---|
| Target port | Gateway Network TLS port, default 8060
|
Cleartext Gateway Network port, read it from the central gateway settings | Any |
| Certificate step | Approve the peer certificate | None | n/a |
| Traffic on the wire | Encrypted | Readable by anyone on the path | n/a |
| Failure if the port is wrong | class error |
CNTL=0x15 (seen here) |
Always fails |
| Result in this installation | Connected after certificate approval | 400 Illegal character CNTL=0x15
|
Failed on the first attempt |
Run option A. It is the configuration that connected here, and it keeps tag and remote-service traffic encrypted between the Edge site and the central server. Use option B only on an isolated lab segment. Even there, confirm with the curl probe that the target port answers plain HTTP.
How do you bring the link up with TLS on both gateways?
- Confirm both gateways run the same version. Connections between editions, such as Edge to a standard gateway, are supported. Mixing major versions such as 8.1 and 8.3 adds another variable, so rule it out first.
- On the central gateway, enable TLS in the Gateway Network settings. Record the TLS port. It is
8060unless someone changed it. - On the Edge gateway, enable TLS in the Gateway Network settings.
- On the Edge gateway, edit the outgoing connection. Set the central host, the central gateway's TLS port, and enable TLS on the connection. Save.
- Open the TLS port inbound on the central gateway's host firewall and on any network firewall between the sites. Re-run
Test-NetConnectionagainst that port. - On the central gateway, approve the Edge gateway's incoming connection and its certificate. If the Edge gateway also lists the central gateway's certificate as pending, approve it there as well.
What breaks this link again, and how do you confirm it is live?
| Symptom | Cause | Correction |
|---|---|---|
CNTL=0x15 returns after maintenance |
TLS was disabled on one gateway, or the outgoing connection was repointed to a TLS port with TLS off | Set TLS on at both ends and on the connection |
| TLS handshake error | Outgoing connection has TLS on but targets the cleartext port | Target the TLS port (default 8060) |
| Connection refused or timeout | TLS port was changed from default, but the outgoing connection or firewall still uses 8060
|
Align the port number in the gateway settings, the connection, and the firewall |
| Link stays pending | Certificate not approved, or re-issued and awaiting re-approval | Approve the certificate on the receiving gateway |
| Mismatch only through NAT or a proxy | Port forwarding lands on the wrong internal listener, or the proxy terminates TLS | Forward the external port to the internal TLS port with the TLS stream untouched |
- From the Edge host, run
openssl s_client -connect central-host:8060and confirm it returns the central gateway's certificate. - On the Edge gateway, confirm the outgoing connection shows a connected status with no error text.
- On the central gateway, confirm the incoming connection lists the Edge gateway by name and shows it as approved.
- Restart the Edge gateway. Confirm the outgoing connection reconnects on its own without a new approval request on the central gateway.
FAQ
Why does the Gateway Network still show CNTL=0x15 after I disable SSL on both gateways?
The outgoing connection is still reaching a port that answers in TLS, most often the TLS port 8060 or a forwarded port that lands on it. Either target the cleartext Gateway Network port, or enable TLS on both gateways and on the connection, then approve the certificate.
Why does the Ignition Gateway Network connection stay down after enabling TLS?
The receiving gateway has not approved the peer's certificate or the incoming connection. Approve both in the central gateway's Gateway Network settings. Approve again whenever a certificate is regenerated or renewed.
is a TLS handshake record, so a TLS client reached a cleartext listener. The fix runs the other way: point the connection at the TLS port, default 8060, and enable TLS on the receiving gateway.
Can an Ignition Edge gateway connect to a standard gateway over the Gateway Network?
Yes. Connections between editions are supported. Run both gateways on the same version, as this 8.3-to-8.3 link did. With TLS on both ends, a correct TLS port, and an approved certificate, the connection comes up.