Opened a case with SUP-152005 describing this issue.
MT answer was:
Thank you for contacting MikroTik Support.
We will see how to improve this.
I hope they fix it, “Routing Rule” has nasty side effects!
There definitely is an issue with Wireguard and two WANS, where one WANTS wireguard to use the secondary WAN.
Mangling does NOT work.
There are two temp solutions
a. Use funky destination nat rule
b. Use routing rules if both wans are static WANIPs
c. Use routing rules with scripts if WANs are dynamic.
Note if doing load balancing as well, mangling takes precedence over routing rules so in the end a. is the better solution.
/ip firewall nat
add chain=dstnat action=dst-nat dst-address-type=local in-interface=WAN2 protocol=udp dst-port=wg-port to-addresses=ip.of.wan.1
This tricks the router to respond to un-destinat any wireguard traffic back to WAN2.
Encounter the same issue : the ouput mangle rule doesn’t capture the WireGuard response ; it goes directly through the default route, ignoring the the mark routing instruction of the output mangle rule.
I opened an issue SUP-158079 : will update this post with Mikrotik support team answer.
Good idea, you can use the dstnat rule work around, it works!
Got response:
Hello,
Thank you for contacting MikroTik Support.
There is alpha74 version in this download link,
https://box.mikrotik.com/d/xxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
Please use it on your device and see if the behavior of Wireguard is different. Let us know your findings.
Best regards,
I testet with ROSv7.15.3 and it works for me WITHOUT the Routing-Rules.
Guys, does it work for you too now? I think so.
I too received such a notification but wasnt sure what to do with it as it was 17 days old and no clear message with the email.
Are you saying that you tested the file they linked to, or that you used 7.15.3 and it worked and the file you linked to was useless information??
I am pretty sure I have seen people using 7.15.3 having the same issue but not 100% sure.
I am using 7.15.3, I cannot install an “Alpha-Version” on my Edge-Router.
Well the question is does 7.15.3 solve the issue for you? You seemed to say so above.
WAN2 with lower distance priority, can be used for wireguard solely based on normal mangling???
I tested it now, DSL has distance 1, LTE has distance 2.
During normal operation (DSL), I connected via LTE to the Wireguard-server. From there I can reach my network. This was not possible in earlier versions.
Using only standard mangling rules ??
Hello, does anyone know if this issue is finally fixed ?
Negative, its not fixed yet but I did send a supout to MT asking for them to incorporate some fixes to make it easier.
In the meantime the workaround which isnt so bad consists of the following:
Basically, setup a faux connection point within the router for the handshake, and then use sourcnat and dstnat to bring the handshake to the wireguard part of the router with modified source and destination addresses. The wireguard protocol on the router will select this faux interface for the return dst for the initial handshake traffic. The router unsourcenats and undestinats the request back to the originator, problem solved.
/interface bridge
add name=br-wg protocol-mode=none
/ip address
add address=192.168.111.10/24 interface=ISP1 network=192.168.111.0
add address=192.168.112.11/24 interface=ISP2 network=192.168.112.0
add address=172.16.10.1/30 interface=br-wg network=172.16.10.0
/routing table
add fib name=via-wan2
/ip route
add dst-address=0.0.0.0/0 gateway=192.168.111.1
add distance=2 dst-address=0.0.0.0/0 gateway=192.168.112.1
add dst-address=0.0.0.0/0 gateway=192.168.112.1 routing-table=via-wan2
/ip firewall mangle
add chain=input action=mark-connection in-interface=wan2 connection-mark=no-mark \
dst-port=13232 protocol=udp new-connection-mark=incomingWAN2 passthrough=yes
add action=mark-routing chain=output connection-mark=incomingWAN2
new-routing-mark=via-wan2 passthrough=no
/ip address
add address=10.20.30.40 interface=lo network=10.20.30.40
/ip firewall nat
add action=dst-nat chain=dstnat connection-mark=incomingWAN2 to-addresses=10.20.30.40
add action=src-nat chain=input connection-mark=incomingWAN2 to-addresses=10.20.30.40
Thank you confirming !
Could be great Mikrotik team fixes the issue, this would avoid these additional dst-nat/src-nat rules...
The problem is that it's entirely unclear what there is to fix and how. Wireguard simply behaves this way, and it's not a bug - it's by design. And it behaves this way on every system (and on every system there are complaints.)
For your specific use case, the solution is to add a single mark-routing mangle rule that marks the output of your wireguard instance appropriately, such as mangle add chain=output protocol=udp src-port=your-wg-if-port action=mark-routing new-routing-mark=your_slower_wan. Additionally, you want an srcnat/masquerade on that outgoing interface, but it's probably there already.
Just to confirm lurker, I wasnt aware there was a new way to deal with attempting to use WAN2 ( secondary wan) for wireguard with just one mangle rule.
My understanding is that we still need to mangle (mark connection and mark route) ensuring that traffic to WAN2 goes back out WAN2, as per normal. Then we need to add a faux interface or real interface that is not going away for any reason. Sindy proposed simply tricking the router based on dstnat rules with wan1, but yourself and cgnnx figured out that it would not work if WAN1 was down.......... so devised using a 'safe' interface to play silly games with dstnat and srcnat rules, to deal with WIREGUARD PROTOCOLs method of choosing outgoing gateway for return handshake traffic.
It's not exactly new, but is was discussed recently. There are two situations that are easy to intermingle in one's head, but upon consideration bear little similarity.
Situation 1: We have two wan connections. We want wg to always answer and then maintain a connection on whichever WAN the connection came in on.
The answer with nat, in all its variations, is the answer to this.
- If we aren't afraid of losing the primary route and address, a dstnat rule to this address is adequate
- If we are afraid of losing the primary wan, double nat has to be done on a virtual address or address pair. There are two slight variations:
- We can assign an address on the loopback and do the nat on that.
- We can assign a pair of addresses on a bridge that's not otherwise connected to anything.
For "reasons", I prefer the latter, but both work equally.
Situation 2. We know that we always want to use a given WAN connection for wg, whatever happens.
This means that we don't anticipate an incoming connection on the non-wg-preferred WAN, and if it does happen, we are willing to push it to the wg-preferred WAN. This also means that any wg connection we ourselves initiate will go through the wg-preferred wan.
For this to happen only a single mangle output rule is necessary to apply the routing mark. Of course the usual srcnat/masquerade rule for that outgoing interface must exist as well.
(I would have loved to properly attribute the proposed solution to whomever came of with them, but I'm afraid I'd make a mistake.)
1 Like
Not my understanding.
If one has two wans and one wants to only use WAN2 for wireguard, you need the complete solution of
a. mangle traffic coming into wan2 (wireguard port udp etc) and then route it out wan2 special table
b. use dstnat and srcnat rule to two different faux bridge addresses or use CGNX simpler LO, one address solution.
Reason being your fighting two situations, wan2 being secondary and the wireguard protocol.
Not solved by a single mangle rule alone.
What am I missing here................ the only thing thats weird in your mangle is some src port thingamabobber and only a mark routing rule.......
It's not that strange. For a connection to be successful, we only need packets to flow in both directions.
From client to router: client simply addresses the router on its WAN2 address. Packets arrive at the wg listener. This side is OK.
From router to client: the router's wg implementation, using whichever address it happens to choose, emits its packet from the port configured on the wg interface. This packet traverses the output mangle chain.
We can identify this packet by a) placing the rule in the output chain (i.e. that it's emitted by the router) and that it's a udp packet from the wg port. We mark this for lookup in WAN2's table. When traversing the srcnat chain, if it doesn't have the correct source address, it's nat-ed.
The connection is complete.
The one dstnat method is still cleaner though... and the double nat ones are actually more functional... and these don't abuse conntrack, so I absolutely would prefer them.
Ahh I get it, so using the source port for the return traffic as the key.......... interesting that it works.
The other solutions are still better, because they use conntrack as intended, even if in a convoluted way.
This last approach is mostly good as a piece of the approach for directing outbound wg connections.