BUG - TLS engine error

Hi Ian,

These are internal debugging messages that have been surfaced in the logs with this text.   Unfortunately, these have not yet been removed from the public EAP images but it will be addressed before GA.  There are few remaining known issues with SSL inspection but you can safely ignore the "internal engine error" messages for now. 

If you have issues with connectivity while using SSL decryption please let us know!

Hi Rob,

I thought that the messages might be an issue because it takes the device two attempts to connect.

Ian

That could be a different issue, unrelated to these messages.  Can you provide more details on the 2 attempts to connect.  @Michael Dunn can you look at this please?

That could be a different issue, unrelated to these messages.  Can you provide more details on the 2 attempts to connect.  @Michael Dunn can you look at this please?

Hi Rob,

the only details I have are in the screenshot I posted above, the device is an IoT which connects regularly to the internet server.

I note at times it makes two attempts, one IP address fails with the error message and the next succeeds, but in this case it was the same server.

Ian

Since the second attempt succeeds, this could be an expected scenario where it does something like attempt a connection, drops it, and the does the real connection.

I don't think we need to investigate right now.

Hi Michael,

that is fine, I raised it and I suspect you have a wait and see what the v18GA fixes?

Ian

Combination of:

Might be fixed already.

No real world impact.

This might be perfectly normal.

As for the latter, the logs will show all sorts of weird behavior from clients that may show as failures but are perfectly normal.

For example:  Download a pdf in a browser.  What you will see is the browser starts the download, see that it is a pdf, and then drops the connection.  It loads the pdf viewer plug-in and then the plug-in downloads the pdf.  If you look at the logs you see a failed download followed by a successful download.  Which is exactly correct.  That is why we try not to start at the log file looking for problems, we try to start at the end user/app having a problem.