Hello,

I upgraded my Mikrotik hEX (RB750Gr3) to RouterOSv7.1rc4 this morning. Great work so far!
I noticed, that WireGuard isn't using the same IP-Address as source for "answers", that was used as destination before. I didn't found similar forum posts, so i describe my issue below.

Real-Life-Example:
My Router has two WAN interfaces using default routes in different routing tables. While the primary WAN interface (CGNAT/100.65.105.240) uses the main table, the secondary WAN interface (195.201.47.xxx) uses another table. I've implemented that with connection and routing marks. That setup works really well for a long time now.

The wireguard interface listens on port 28563 and is reachable over the secondary WAN interface (packets arriving at the router).
This is a connection-table entry for an incoming connection: The problem is, that outgoing packets not using the correct IP-Address as source (195.201.47.xxx in this example) but 100.65.105.240 from the primary WAN interface, causing a new connection-table entry, so answering packets aren't mapped to the correct connection-table entry from the screenshot above: This leads to miss-routed packets with a wrong source-address: The connection cannot be established.

I know, that Wireguard uses the connection-less UDP, so I tried to reproduce that with a wireguard interface on a Linux machine with two ip addresses on a single network interface. The linux machine uses the correct IP-Address as source for answering packets. It doesn't matter, if I use the primary or secondary address as destination there: I tried some workarounds with output mangling and src-nat. But that doesn't work either.

Maybe you can help? If you have questions about that, just ask!

EDIT:
I tested three other scenarios on Mikrotik.
1.: TCP-Connection to the secondary WAN IP (195.201.47.xxx / SSH): Returing packets are routed correctly via the secondary IP/interface/connection-table-entry. Works.
2.: Wireguard Connection to an (internal) interface with two IPs (like the test on the Linux machine): Works on both IPs as intended.
3.: Wireguard Connection from an internal interface to the secondary IP (195.201.47.xxx): Works, IP and connection-table-entry is mapped correctly.

I think, the problem cause may lies in the use of different routing-tables?

EDIT END.

Greetings from Germany,
Erik.

Hi,
I have a hap ac^2 and had very similar issues a couple of ROS versions ago (and older).
With both wireguard and openvpn(udp) But for wireguard (only) it has been fixed (fully? not sure)
I assume the fix would also apply to the HEX.
It is now working, I am using routing rules for the routing.

They are something like:

If destination ip is in private address range then lookup main table (3 rules)
if source ip is router-wan1 then lookup via-wan1
if source ip is router-wan2 then lookup via-wan2
if routing mark is via-wan1 then lookup via-wan1
if routing mark is via wan2 then lookup via-wan2

I also have an early accept mangle rule on output, when the udp source port is wireguard (or openvpn)
So no routing marks get applied to it.

Hi,
I was a little busy last week. Sorry for my delayed answer.

Your hint with simple routing rules did it! I created two policy routing rules inspired by your example:
SRC: 195.201.47.xxx/32 (IP Address from secondary WAN-IF); Min-Prefix: 1; Action: Lookup; Table: main
SRC: 195.201.47.xxx/32 (IP Address from secondary WAN-IF); Action: Lookup; Table: Secondary-WAN-Table The first rule looks up the best route in main table, if there is a better one than default (e.g. for internal connections). When there is no such route (e.g. internet ip-address), then lookup is done in the Secondary-WAN-Table (which only has a default rule)

The outgoing Packets have the right IP now and are mapped to the right connection-table entry. I'm still not sure, if that is a expected behavior, but it works for me.

Thank you very much!

Erik

TL;DR for other users with the same problem:

WireGuard doesn’t recognise (output) mangle rules.
You have to use PBR Rules!