Gateway Network 2 Good Connections, 1 with Unknown Gateway Name

I have 2 Gateways configured with outgoing connections and another to which they are connected. I have a third gateway with an outgoing connection to the same receiving gateway. This third one requests a connection which I approve, but in the Incoming Connections list of the receiving gateway this third one only shows "Unknown" for the Gateway Name and the Redundancy Role.

I've looked extensively here and elsewhere on the internet, where it was suggested that I try having the third outgoing gateway regenerate its certificate and gateway name. Neither of these things helped.

Any other ideas would be appreciated. Thanks.

Are there any error logs on the gateway that has the third outgoing connection?

I found this in wrapper.log on the failed outgoing gateway connection:

INFO | jvm 1 | 2026/09/03 15:11:25 | Exception in thread "gn-bpmignition:8060-recv-3" java.lang.IllegalArgumentException: Unsupported CipherSuite: TLS_KRB5_WITH_3DES_EDE_CBC_SHA
INFO | jvm 1 | 2026/09/03 15:11:25 | at java.base/sun.security.ssl.CipherSuite.validValuesOf(Unknown Source)
INFO | jvm 1 | 2026/09/03 15:11:25 | at java.base/sun.security.ssl.SSLSocketImpl.setEnabledCipherSuites(Unknown Source)
INFO | jvm 1 | 2026/09/03 15:11:25 | at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:414)
INFO | jvm 1 | 2026/09/03 15:11:25 | at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:384)
INFO | jvm 1 | 2026/09/03 15:11:25 | at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
INFO | jvm 1 | 2026/09/03 15:11:25 | at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376)
INFO | jvm 1 | 2026/09/03 15:11:25 | at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
INFO | jvm 1 | 2026/09/03 15:11:25 | at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
INFO | jvm 1 | 2026/09/03 15:11:25 | at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
INFO | jvm 1 | 2026/09/03 15:11:25 | at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
INFO | jvm 1 | 2026/09/03 15:11:25 | at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
INFO | jvm 1 | 2026/09/03 15:11:25 | at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
INFO | jvm 1 | 2026/09/03 15:11:25 | at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
INFO | jvm 1 | 2026/09/03 15:11:25 | at com.inductiveautomation.metro.impl.protocol.websocket.WebSocketConnection$RunDownload.run(WebSocketConnection.java:1998)
INFO | jvm 1 | 2026/09/03 15:11:25 | at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
INFO | jvm 1 | 2026/09/03 15:11:25 | at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
INFO | jvm 1 | 2026/09/03 15:11:25 | at java.base/java.lang.Thread.run(Unknown Source)

I don't know why this gateway would have a different SSL cipher than the rest. Maybe I'm reading too much into this?

I removed the whitelist of ciphers in the Networking>Web Server parameters since this was the only machine that had a list.

Still no luck.

I believe this means that the incoming gateway is using that CipherSuite, but the outgoing gateway is not. There is a system property that you can set in data/ignition.conf where you can change which ciphers are used. It would look something like 'wrapper.java.additional.1=-Dciphers=X,Y,Z' or 'wrapper.java.additional.1=-DexcludedCiphers=X,Y,Z'. See Web Server Settings | Ignition User Manual and maybe Gateway Configuration File Reference | Ignition User Manual

My best guess is that the incoming gateway is using some non-standard cipher suite and the outgoing gateway hasn't been equipped to use it. It might be best to take a look at data/ignition.conf on the functioning outgoing gateways and see if they have been customized with cipher suites.

This took care of it. When I removed the whitelist in the web interface, I thought it had done this too.

I deleted all of the names here and restarted the gateway. Everything works fine now!

Thanks.