Version number: RouterOS 7.1beta2
Router's model: CCR1009-8G-1S
Configuration export: https://0x.ms/GU824etAtUN/text
Kernel panic backtrace: https://0x.ms/HkEjA4EgX1o/text
Steps to reproduce the issue:
Create a basic Wireguard tunnel between Linux kernel version 5.4.0-1018-aws (Ubuntu 20.04 LTS running on AWS Lightsail) and MikroTik CCR1009-8G-1S running RouterOS 7.1beta2.
Once tunnel is up and handshake OK, the important part which causes the kernel panic is to ping the remote end from a device behind the MikroTik on a bridge.
Detailed description / extra information:
You don't even need to add a firewall rule allowing the ping from the device to the remote end. Simply attempting to ping the remote end from a device causes a kernel panic.
In my case, I am pinging form 10.100.0.178 (my computer) to 10.100.9.2 (remote Wireguard server). The router has IP 10.100.9.1.
When pinging remote end directly from router, there is no kernel panic, but the ping does not work in any direction. Traffic can only go from the MikroTik router to the remote end, from remote end to MikroTik.
"wg show" command from remote end: https://0x.ms/FX9qX65Isdf/text
tcpdump from remote end when pinging from MikroTik router to remote end: https://0x.ms/E8yNpqcjtpw/text
tcpdump from remote end when pinging from remote end to MikroTik router: https://0x.ms/CFThgRp56SS/text
Both tcpdump commands above were ran with all firewall filter rules disabled.
As is clear from the tcpdumps above, the MikroTik router receives no packets over the Wireguard tunnel from the remote end, but the remote end can receive all packets from the MikroTik router.
Can send latest autosupout.rif to any MikroTik employees, just ask.
Please also ask me for any further explanation or further information, I will be glad to help debug this issue in any way I can.
Thanks for releasing a beta version of RouterOS v7 for us to test and thanks so much for taking the time to add support for Wireguard :)