(1) Why the four or five wireguard interfaces. I like simple and clean. Unless there is a reason to have four or five you only need one interface!
You can actually define and use multiple IP subnets to a single wireguard interface.
The only reason you would need multiple INTERFACES is if there was any router traffic that needed to go out the internet on the remote end.
Then you would have to use 0.0.0.0/0 on the allowed peer settings, and thus not possible to have more than one peer effectively.
(2) What a mess, you have bridge but dont use bridge vlan filtering............................... as I stated simplify.
Nothing to be gained by the over complex structure.
(3) For example why do you have two management subnets..........makes no sense
(4) Rp filter strict is a no no especially in multiwan scenario, should be set to LOOSE
++++++++++++++++++++++++++++++++++++++++++++
This is a client router and I'm coming in after its been deployed and their last network guy left.
I agree the vlans need to be cleaned up, its a mess along with a bunch of other things.
I'd like the is thread to focus on the WG issues with multi wan.
After our last discussion, I did find and change the RP filter to loose.
The client has had multiple WG interfaces since before I took them on.
wireguard1 - has both roadwarrior and a site to site tunnels. Meant to come in on WAN1
wirenetlife - has both roadwarrior and a site to site tunnels. Meant to come in on WAN2
wiregrelive - has only roadwarrior tunnels, meant to come in on WAN1.
wireguard2-test - was set up as a brand new test for me to see if the problem stemmed from prior setup. This will be deleted
While I'm confident I can merge wiregrelive and wireguard1 together, that doesn't solve the core issues I've reported in this thread.
There are bandwidth and latency reasons why certain connections need to come in WAN1 and not WAN2, and vice versa. Once I have this issues sorted, WG ports will only be allowed in via their respective WAN interfaces.
You asked for the config, I've provided it.
I listed the mangles above, and in the config. I'll list them again in case you missed them.
/ip firewall mangle
add action=mark-connection chain=input comment="Keep eth1 inbound connections to eth1" connection-mark=no-mark in-interface=ether1 new-connection-mark=ISP1-IN passthrough=yes
add action=mark-routing chain=output comment="Keep eth1 connections to eth1 - mark route" connection-mark=ISP1-IN new-routing-mark=ISP1 passthrough=no
add action=mark-connection chain=input comment="Keep eth2 inbound connections to eth2" connection-mark=no-mark in-interface=ether2 new-connection-mark=ISP2-IN passthrough=yes
add action=mark-routing chain=output comment="Keep eth2 connections to eth2 - mark route" connection-mark=ISP2-IN new-routing-mark=ISP2 passthrough=no
I've added these DSTnat rules per your recommendation.
/ip firewall nat
add action=dst-nat chain=dstnat comment="WG Fix for Eth2" dst-address-type=local dst-port=23232-23239 in-interface=ether2 protocol=udp to-addresses=WAN1IP
add action=dst-nat chain=dstnat comment="WG Fix for Eth1" dst-address-type=local dst-port=23232-23239 in-interface=ether1 protocol=udp to-addresses=WAN2IP
During my tests, from my home ISP, I can handshake with all WG instances via WAN1 and WAN2, however, from my home ISP, I cannot route any actual traffic. (like checking ipinfo.io)
However, if I test using my cell phone with the exact same WG peer profiles, WAN2 instances work, but, and only wiregrelive works via ISP1.
It's completely inconsistent.
My only guess is that there's some kind of hashing algo related to ECMP that's happening with each WG instance in RouterOS, and once that has has been made, it stay resident in memory until the unit is rebooted. If we reboot the device, WG could work fine via WAN1, or only work via WAN2.
