Nimbostratus
Employee11.3.0 is well out of support by now, but having said that, I don't think anyone has updated the 90-day trial to a more recent version. Speak with sales if you would like to trial a more recent version.
The CMI channel is the connection used to perform configsync, which is separate from the HA failover capability.
The things you've tried are all good ideas, although you should be attempting to connect to tcp/4353, not 6699 (it arrives on 4353, and based on the SNI value in the certificate, it is translated internally to 6699, and visa versa)
One of the more common causes for CMI dying in those older versions of software was running out of RAM (which caused inactive TCP connections, including the CMI channel, to be killed off) due to leaks or overcommittment. Does the problem go away if you reboot both LTMs ? Do you see many occurrances of the message "sweeper_update: aggressive mode activated" in the ltm log ?
I've also seen expired device certificates cause this sort of problem - did the LTMs have NTP time sync with an external clock when the device certificates were first generated ? (check the expiry under system / device certificates / device certificate)
If that doesn't help, try turning on debugging and see if that sheds any light on the matter:
tmsh modify sys db log.ssl.level value Debug
tmsh modify sys db log.tmm.level value Debug
Set them both back to value 'notice' after collecting the data, and check both /var/log/ltm and /var/log/tmm for messages.
You could also run "tcpdump -i0.0:nnn -s0 tcp and port 4353" to see what the tcp reset cause is when the connection is being closed.