Hi, hope someone can help here.

My ISP provides two ip addresses. The primary IP I receive via dhcp which also provides a default route. The second IP I have statically assigned to the same interface.

All traffic initiated at the router goes out the default route.
Wireguard handshakes coming into the second IP handshake successfully and returns out the second IP. This is good.

But, wireguard handshakes initiated at the router still go out the default route with the primary IP. I want that traffic to also use the second IP.

I have tried a number of mangle approaches and routes but am unsure how to force the outgoing handshake to use the second IP.

Maybe a simple solution? I might be doing it wrong.

Common problem
Search for wireguard DSTNAT in the search, there is a fix and its known

Thanks anav, that thread and your solution are what I was using but unfortunately did not work and I don't think thats what I need. Please let me know if I am off base.

They had two interfaces each with a single IP. I have one interface with two IPs.
Traffic coming in on one of their interfaces was not going out the same interface. That is working actually fine for me so I don't think I need dstnat.

I simply want new handshake traffic that initiates at my router to pick the second ip.

cant help much else without seeing the full config
/export file=anynameyouwish ( minus router serial number, any public WANIP information, keys etc..)

Also do a print of your ip routes ( again not exposing any public WANIp information )

Thanks anav, I was overthinking this I think. I just needed to override my default srcnat rule. Placed this as first nat rule and seems to be working correctly.

/ip firewall nat
add action=src-nat chain=srcnat comment="wg over second ip" out-interface-list=\
WAN protocol=udp src-port=<wg port> to-addresses=<second ip>

If its working and you are happy stick with it.
It is not the correct solution if the problem is the same as many others have encountered which is.

PRIMARY WAN
SECONDARY WAN ( failover wan ) - when one wants to use the secondary WAN for VPN wireguard

Situation after Proper Wireguard setup -->Wireguard still does not work!

Observation: MT Router receives handshake and sends response out Wireguard1. This is fully expected as WAN1 is primary to all traffic will exit via WAN1

Normal Remedy: Mangle incoming traffic on WAN2, so that return traffic also comes out WAN2, works for all other traffic.

/routing table
add fib name=use-WAN2

/ip nat mangle
add chain=input action=mark-connection in-interface=WAN2 connection-mark=no-mark \
new-connection-mark=incoming_w2 passthrough=yes
add chain=output action=mark-routing connection-mark=incoming_w2 \
new-routing-mark=use-WAN2 passthrough=no

/ip route
add dst-address=0.0.0.0/0 gateway=wireguard routing-table=use-WAN2

Observation1: External Users can now ping WAN2 and get a response from WAN2 (a false hope LOL)
Observation2: External Users cannot connect via WG?? Handshake return is NEVER received.

PROBLEM: Despite mangling the Router still sends out Handshake response out WAN1

Resolution: Apply a destination NAT rule that tricks the Router into thinking that all such traffic originated from WAN2 and needs to be un-sourcenated to WAN2.

/ip firewall nat
chain=dstnat action=dst-nat dst-address-type=local in-interface=WAN2 protocol=udp dst-port=WG-endport to-addresses=ip.of.wan1.PRIMARY


Solved most peoples problems including my own testing!

+++++++++++++++++++++++++++++++++++++++++++++++

I didnt try this approach but it may work.... ( no mangling )

START FROM SCRATCH

/routing table
add fib name=use-WAN2

/ip route
add address=0.0.0.0/0 gateway=wan2-gatewayIP table=use-WAN2

/routing/rule
add action=lookup-only-in-table src-address=fixed-static-public-IP-of-WAN2 table=use-WAN2

Check if successful ---> IF NOT add the dstnat rule above, and then recheck.

Thanks for the excellent write up.

I do think it is interesting to note this behaviour. If traffic comes into wireguard on a specific ip on a single wan interface it will return out the same ip regardless of default route, aka connection tracking is working as expected.

The scenario you are describing with multiple wan interfaces and connection tracking not working really does seem like a bug and will hopefully be fixed.