the "target" devices are indeed mipsbe ...
dude is running on a dedicated RB750GR3 mmips
Probably. Checked on 7.23.5 and the output is as expected. 7.23.6 and 7.24.3 seem to be rushed.
I suspect this for the identity print:
and for the LTE firmware removal issue this one:
Watch out for "improve stability" in future changelog.
using legacy wireless on ac2. after upgrading, all device(s) cannot connect to ac2 (as main dumb ap). on windows (laptop) appears SSID (Hotspot 2.0). didnt config my wifi to that setting/config. after rebooting, the problem disappear and back to normal.
I have similar setup. Dude connects to ARM and ARM64 devices fine, but stays at "connecting" with MIPSBE devices. Filed ticket to support
P. S. Problem was there in 7.24.3 as well.
same problem to a client running 7.24.4 ...
Yes - I downgraded target device to 7.24.2 and that solved the problem. Probably 7.23.6/7 -> 7.23.5 path should help in similar way
RE: SCEP . . .
No, and the error isn't actually SSL/TLS, it's an outright fail of tunnels to com up from and client or platform with:
OVPN: <aaa.bbb.xxx.yyy>: disconnected <unknown cipher alg or key size>
I have not yet tried rebuilding the config, but somewhere between 7.23.3 and now this dies across the board with the only change being the update. (7.23.5 reversion did not help either . . . and have not tried .7)
Don't bother with 7.23.7; it's the same.
MT reply
7.23.6 added certificate/crypto changes, and the issue reproduces only there. The SSTP session itself stays up, so these appear to be failed handshakes.
I wonder if it somehow broke the certs (self signed in this case) . . . fallback didn't help . . .
Same issue here. I asked them the same question and will share their response when they reply.
We have identified a critical connectivity issue following the recent update to version 7.23.7 on the RB2216. The 100G link connected to the Huawei CloudEngine 6730 switch has stopped functioning correctly. The corresponding physical port is exhibiting "flapping" behavior (intermittently dropping and reconnecting), preventing traffic stabilization.
Looking at this a bit deeper from my Linux box, it looks like some of the Ciphers are not working. On this system, if I specify a ciper of "AES-256-GCM", the link will come up and run. If I specific any of hte AES-?-CBC ciphers (clearly selected in the test server), I get the "no cipher found" error . . . Not sure what the Whinders and Android OpenVPN clients are trying to negotiate at the moment, but will get back over there and see if forcing that is a workaround. Overall, though, I've done nothing with certs and at least this combo is working. (I seem to recall something about the Android client, at least, not supporting all ciphers though . . . Hopefully not a complete mismatch.)
Hmmm . . . One *win system with that specifically set seems to be working. Not sure what's up on the other one . . . or the Androids . . .
Another update . . . Test OpenVPN server config is this:
add auth=sha1,sha256 certificate=server-cert cipher=blowfish128,aes128-cbc,aes192-cbc,aes256-cbc,aes128-gcm,aes192-gcm,aes256-gcm comment=xxxxxx default-profile=TPC disabled=no mac-address=XX:XX:XX:XX:XX:XX name=xxxxxx port=35234 push-routes="<redacted>" require-client-certificate=yes
The OpenVPN client on my Linux box supports all those and more . . . Testing each cipher, I find this:
AES-128-GCM - Works
AES-192-CGM - Failes as noted "unknown cipher alg or key size"
AES-256-GCM - Works
AES-128-CBC - Fails as above
AES-192-CBC - Fails as above
AES-256-CBC - Fails as above
Blowfish-128 (BF-CBC in OpenVPN) - Works
Logs on the OpenVPN client show perfect TLS negotiation and Cert validation, the connection just dies with:
2026-09-17 12:41:11 Connection reset, restarting [0]
Looks like if I force that cipher, anything but OpenVPN for Android 0.7.65 can be made to work . . . So, not as bad as it seemed. The inop/broken ciphers have been reported on SUP-224147.
CBC ciphers are often insecure and deprecated. They are probably disabled on purpose in some modern clients.
The clients VERY CLEARLY show them (openvpn --show-ciphers) supported that I am testing with, as does the Mikrotik. Good or not is irrelevant here - they should work. (And if you set an unknown on the client, OpenVPN refuses to start . . . not happening here . . . )
Note also that AES-192-GCM fails as well, but -128- and -256- work. If Mikrotik should want to pull them, fine . . . But they currently are choices and should at least try to work.
(And not sure something else goofy isn't going on . . . One system would not work at all yesterday, but after copying the OVPN server to a test one (identical, diff port) I can't make it fail again to either . . . )
As for the Android app, I managed to get it working—since I was getting the same error—by entering the following text in the OpenVPN profile under the "Advanced" section > "Custom options": --cipher AES-256-CBC
xxx.yyy.zzz.aaa: using encoding - AES-256-CBC/SHA256
Which Android app? "Open VPN", "OpenVPN Connect", or ??? With the former, syntax is a bit different (in gens the config based on the gui . . . ) and despite seeing it there, I still error. The other works fine.
(Found that in OpenVPN . . . I wonder if the app is broken. I defined that in the GUI, but it created a "data-ciphers" parameter that I have never seen in OpenVPN . . . adding "cipher AES-256-GCM" worked for me as well.) I also noted something along the lines of "no cipher selected" in the client log as well - I think the config generator went FUBAR on the 9/6/2026 build . . .
The app is openvpn for android 0.7.65, I noticed that, despite having set the value in the cipher field in the GUI, when starting the connection I received a "cipher not set" warning (in the log, during the initial phase) . I think there's a bug in the app.By configuring it as I mentioned earlier, the warning disappeared.
Yup . . . you get the "data-ciphers" entry with the gui value, which the underlying OpenVPN code appears to ignore.
Deprecated parameter --cipher was used in older versions of OpenVPN to select exactly one cipher that should be used, newer versions use --data-ciphers to define a list of ciphers that can be negotiated and used, like AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305, and value you specify as --cipher is just added to that list.
There is also --data-ciphers-fallback and it is used as a fallback if we cannot negotiate the cipher so you may try that instead, but that would mean that MT OpenVPN implementation does not support NCP correctly...