Ah, great! I was looking for an example of that, but did not find it (I thought neighbor discovery settings had it, but it offers no plain interfaces). Indeed that screen has exactly what it should be in the ipv6 nd settings, and probably in almost every place where you can select an interface.
You don't need to look that deep, even the bridge port selection, or the VLAN tagged/untagged lists have since long had such dropdown lists.
Ah yes, I was sure I had seen it but when looking for it I could not find such a place. Indeed there it is available as well.
I would hope that RouterOS could be even smaller when such things are standardized to behave the same in all places and can use a single function shared everywhere, instead of custom code for each place.
L009 with 64 bits problems solved with latest RC.
I noticed that Wireguard peers do not come back after a reboot. I haven't been able to pinpoint the exact cause/behavior. It doesn't happen all the time, there need to be specific conditions to occur.
Downgrading to v7.23.2 resolves the issue.
@EdPa a few minor issues if you please
/ip socksify socks5-passwordnot marked as sensitive despite containing password (/export show-sensitiveis not necessary)- netwatch | RouterOS Manual and in other places - "host ( mandatory ) address (flags=46viD) The IP address or domain name of the server to be probed. See address flags" - link to
address flagsis broken - netwatch | RouterOS Manual - "early-success-detection ( unset ) bool Netwatch will not wait for all the packets to be processed to change probe status if it is already known that the host will be
considered "Down". This parameter is specific to the ICMP probe type. (default value: no)" - should beconsidered "Up"(early-failure-detectionis right)
Could you kindly flag them to be fixed?
I noticed strange behaviour related to /ip socksify that might be erroneous.
If you chain https proxy inside socks proxy via curl (e.g. curl --preproxy socks5://socks_proxy --proxy https://https_proxy/ --proxy-http2 --proxytunnel --resolve download-cdn.jetbrains.com:443:13.226.155.11 https://download-cdn.jetbrains.com/go/goland-2025.3.3-aarch64.dmg --output /dev/null), everything works alright.
If you /ip socksify socks proxy (e.g. /ip firewall nat add action=socksify chain=dstnat dst-address=13.226.155.11 protocol=tcp socksify-service=service1) and only run the query via the https proxy (and RouterOS will chain it to socks proxy for you) but still in HTTP2 mode(!) (e.g. curl --proxy https://https_proxy/ --proxy-http2 --proxytunnel --resolve download-cdn.jetbrains.com:443:13.226.155.11 https://download-cdn.jetbrains.com/go/goland-2025.3.3-aarch64.dmg --output /dev/null) it will error out at some point
* OpenSSL SSL_read: OpenSSL/3.5.7: error:0A000119:SSL routines::decryption failed or bad record mac, errno 0
* OpenSSL SSL_read: OpenSSL/3.5.7: error:0A000139:SSL routines::record layer failure, errno 0
* Failed receiving HTTP2 data: 56(Failure when receiving data from the peer)
* OpenSSL SSL_write: SSL_ERROR_SYSCALL, errno 0
* OpenSSL SSL_write: OpenSSL/3.5.7: error:80000000:system library::Success, errno 0
curl: (56) OpenSSL SSL_read: OpenSSL/3.5.7: error:0A000119:SSL routines::decryption failed or bad record mac, errno 0
It might error out at 100MB downloaded, 200MB, 500MB, 720MB, but it errors out every time.
GnuTLS errors out immediately
* Establishing HTTP/2 proxy tunnel to download-cdn.jetbrains.com:443
* GnuTLS recv error (-9): Error decoding the received TLS packet.
* Failed receiving HTTP2 proxy data
* closing connection #0
curl: (56) GnuTLS recv error (-9): Error decoding the received TLS packet.
Removing HTTP2 proxy mode (--proxy-http2) solves the error for both.
I don't control the proxy so I cannot check what's happening on the other side.
Could socksify implementation be responsible? It's the only variable I change. When curl chains itself, everything works.
P.S. CRS309-1G-8S+IN.
Seems to work fine on my rb5009.
I use the BackToHome feature which uses Wireguard and it keeps working also after a reboot of the rb5009.
I didn't have time to troubleshoot any further. It happened three times after reboots and I just downgraded for the time being.
It doesn't fail just because of the reboot. Apparently there are other variables to this that cause the issue. I won't be able to get back to this before September. Hopefully until then someone else may figure it out and report it to support.
Considering that there have been wireguard changes on this release though, it makes sense that there are new bugs introduced. I haven't had an issue with wireguard for a long time until now.
If all continues as it has been for a while, it might be possible for Mikrotik to become "Dropbox of a networking world" - Dropbox had a data leak in 2012, which they essentially covered up until all leaked dataset (data of over 60 million accounts) leaked out into public 4 years later.
Be happy that there is no Bitcoin Wallet app in the container app store!
After last week, everyone wants a ColdCard App!
lol, don't give them ideas! 
Installed on fresh hAP be lite to have latest-greatest of WiFI7, but device self-restarted 2-3x/day.
7.23.3 seems to run more stable.
Did you upgrade firmware as well?
It would be nice to contact support and provide them with a supout.
Yes, of course. Support got the supouts.