(This is a cross-post of my analysis and solution from https://forum.mikrotik.com/viewtopic.php?t=197545 to get more eyes on it) -- I've reproduced this in GNS3, and I'll submit it to MikroTik support as well, but here's the bug we're discussing here. Network topology Screenshot 2023-07-06 at 12.14....

I've reproduced this in GNS3, and I'll submit it to MikroTik support as well (Edit: Done, ticket number SUP-121220, feel free to reference this in your own bug reports!), but here's the bug we're discussing here. Network topology Screenshot 2023-07-06 at 12.14.27.png Entire (relevant) router config ...

Thanks for your quick responses, much appreciated.

Any chance you could please post the relevant config snippets? EDIT: I've since solved this with a simple, sane but rather unnecessary SRC-NAT rule - forcing the WireGuard daemon to think the connections are coming directly from the other end of the local WAN link and thus needing to reply that way ...

This is not just happening to you, I can definitely reproduce this.

I'll build a simple config to reproduce this and post here tomorrow if I get time. In the mean time, following for potential work-arounds!

anav and manojlovicl, do you have an example of the NAT you implemented please? I am hitting the same bug, where the WireGuard service is latching onto the main table, regardless of route or mangle rules. I can see the incoming connection correctly marked in the Connection Tracking table, and its RX...

Has there been any progress on this? I'm seeing these exact symptoms moving from 6.7 to 6.9, 6.10 or 6.11 (I don't have 6.8 to test with). As mentioned here, downgrading to 6.7 resolves the issue again.

Do I need to also contact support? Multiple route tables is kinda crucial to my config.

I read it as 10dBi of extra gain on top of the 16dBi already provided by the SXT's built antenna - for a total of 26dBi per end.