Hello.
When responding to a client request, the WireGuard server uses as the source IP not the IP to which the request was received, but the IP of the interface corresponding to the route to the client. Is there any way to change this logic?
src-nat
Not sure what you mean…
a. If a user has a destination address, that by the configuration of the router, means the traffic will enter the wireguard tunnel and at the other end the source address of the incoming traffic will be seen as the user IP.
b. Is the router has setup sourcenat such that any users IP address, will be changed to the local wireguard interface IP, then all users will have that single wireguard IP address as source when it reaches the other end of the tunnel.
The problem described concerns only the establishment of a client-server connection.
Here is an example diagram of a connection establishment problem.
Default route in RouterOS 1 for 2.2.2.2 via 192.168.1.1
It would help to see the full route table on RouterOS 1, but based on the diagram alone, this looks to be expected. Your ROS 1 has a directly connected route to 192.168.1.1, so it will use that. And because that route belongs to the interface with 192.168.1.2, that’s what it will use as the source.
Can you explain what you are trying to achieve?
I think the best summary of the Wireguard behavior and possible ways to address multi-WAN scenarios is here.
Why then do other services work differently, for example, the same WinBox on port 8291 correctly responds from the address 192.168.2.1 to which the request was sent?
The main idea is to make a fault-tolerant WireGuard server, each of which is configured identically on its own instance of the VRRP cluster.
Because Wireguard is UDP-based and has an embedded handling of roaming. Like everything, that appropach has both advantages and drawbacks.
So, is the observed problem a feature of using UDP, a feature of the WireGuard protocol, or is it simply a decision made by the developers at MikroTik?
A feature of the Wireguard protocol. Mikrotik pretty much uses the reference implementation.
Thanks for your help, everything worked out!
I jumped to conclusions. In my case, the connection is unstable, and this is most likely due to the fact that the VRRP gateway is used as the source IP address.
To solve the problem, I added an IP address to the lo interface, and registered a route to it on the 3rd-party gateway.
In this case, I only needed to create one rule for NAT:
/ip address add address=10.0.1.1 interface=lo network=10.0.1.1
/ip firewall nat add action=src-nat chain=input dst-address=10.0.1.1 dst-port=13231 protocol=udp src-address=2.2.2.2 to-addresses=10.0.1.1