So, I've managed to set a working tunnel, but for some reason, when I just masquerade it, Internet on connected devices to MikroTik stops working. Changing it back to out-interface "internet" (WAN - ethernet port connected to another router), solves the problem. Now, I want everything connected to my mikrotik to use wireguard. If I remove the default route from DHCP client on the WAN interface and add a direct route to the IP of the wireguard server through the gateway on WAN interface, then internet on the connected devices work. But since the IP of the wireguard server is changing every 24h, I can't have a static route directly to it through the WAN gateway... and that breaks everything.

So... my main router is at 192.168.88.1, my mikrotik has DHCP assigned 192.168.88.81 and the wireguard server is on the internet on a dyndns hostname.
The network which needs to use wireguard is 192.168.156.0/24. Mikrotik assigns devices their IP via DHCP normally in that range.

The way I see it, I can't tell Mikrotik to use 192.168.88.1 as default gateway for reaching the dyndns hostname and using a wireguard as out interface for the 192.168.156.0/24 network for reaching 0.0.0.0/24 because dyndns hostname is also in the 0.0.0.0/0 range...

I may have overcomplicated it, but I hope you'll understand where the problem lies and if there is a solution to it... thanks!

You may try to describe as much as you want but it will be a lot easier if you open a terminal:
/export hide-sensitive file=<anynameyouwish>

And then post the contents of that file between Code quotes.
A lot easier for anyone to see what your config looks like.

PS and yes, most likely there will be a solution

The Mikrotik actually does not have any previous configuration. I've just resetted it to the defaults as the idea is to make the setup to work from anywhere.

One device connected to the Mikrotik should connect to the internet over wireguard link, wherever the Mikrotik is plugged in. So imagine that you can't actually change the WAN side, it's wired and there is a DHCP waiting.

Imagine this diagram:



So.... the device when it goes to "whats my ip" has to have endpoint's IP... that is all needed.

What can be configured - only the Mikrotik acting as a wireguard client.

How it's done, it really doesn't matter.

Why? Because the "device" is behind a CGNAT and the device needs an open port to function properly, while the endpoint (wireguard server) has a public IP with all ports available and accessible. That's it!

I've solved that with netwatch, but the problem here is (thanks to mkieeg02 from mikrotik discord) that this works - when my endpoint IP is a known IP... and then adding a masquerade rule for wireguard1 as out interface

If it's done this way, everything works like I hoped to... BUT... since I don't know the public-ip-of-endpoint as it changes often, I can't pust a hostname into a dst-address line... and can't put 0.0.0.0/0 as that route already exist for all other traffic (the 192.168.88.1 is gateway for all traffic)...

And then if I do this...
and then add a masquerade rule, then local subnet or IP can't go through wireguard at all.

so, I'm guessing it has to do with routes.....

Use dynamic dns service to "fix' the changing ip address on the other side. Use that name as endpoint.
You may are may not have that already covered.

Then set your 0.0.0.0/0 route for wg to the wg interface itself with a distance lower then the default ( you may have to look for that default to give it a higher distance)
If wg ITF is down, that route becomes invalid and will not be used.

Would all be easier to comment with a config export ... yes ?

Here is the config which is bare as it can be as the Mikrotik in question is reset to defaults:


(there are some leftovers from previous tries to make this work)

Now... see this...



So... from Mikrotik itself the Wireguard tunnel works.
When I connect a device to wlan1 (which is in a bridge with ether2-ether5), it normally gets an IP from DHCP, but the internet on the device doesn't works. The wireguard1 interface is masqueraded.

It should work, but it doesn't.

I installed an Android wireguard client just to test if the endpoint works - and guess what - I just copied all the info from Mikrotik into the application - and it connected, Chrome showed endpoint's public IP. So the tunnel is confirmed and working. Application can connect to a tunnel just like Mikrotik can. But why devices connected to Mikrotik can't, that remains a mistery...

So long story really short:
tunnel works, mikrotik connects, all good.
devices connected TO mikrotik can't use the tunnel!

I dont understand your network diagram in the slightest.
Let me see if I can make guesses.

You have a MT device behind the main router in your network.
It is setup as a router (double NAT) and you are using this to connect to the wireguard tunnel as a peer device).
You have a device behind the MT router (on the MTs LAN) that needs
a. to go out the remote wireguard server connection??
b. to reach LAN subnets on the remote wireguard server connection??

What is at the remote host (wireguard Server end) It is not clear??

(I see anav is confused as well)
My guess:
We're talking about a Mikrotik device here in some sort of road warrior mode ?
The MT is mobile and you want it to 'phone home' through wireguard ?

For future: use export with hide-sensitive... all your connection info is visible.

Couple of remarks from my side, surely others will have other things to say:
firewall
I hope that Mikrotik is not connected to a public internet port yet ?
It's really wide open !

/interface list
I don't get why you put wireguard as WAN. It's a trusted interface as consequence of the private/public key exchange, no ? Usually this is set as LAN and will save you some other headaches later on if you want to connect remotely to your Mikrotik. So, make that LAN.

Can you also show this
I don't see ANY routes. I think the issue might be there.
It should at least have 0.0.0.0/0 -> wireguard1, right on top.

Assessment of CONFIG
Assuming the MT is a client wireguard router device

(1) The MT client router device does not need a listening port?? It is reaching out to the remote wireguard server (which should have a listening port).
(2) THe wireguard interface is NOT a wan or LAN interface. Remove.
(3) The only thing required here is a route to ensure all requests from wireguard clients go out the WG interface~~

IP Route
0.0.0.0/0 gateway=WG

(4) Missing the IP address STATIC WANIP from the main router (aka the correct LANIP on one of the main routers subnets).
If its a static you dont need this line
/ip dhcp-client
add comment=defconf interface=internet from the main router,

Furthermore why do you have an LTE setup here??


(5) What is this doing on the Router , just remove it.
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan

(6) mangling not required,
REMOVE
/ip firewall mangle
add action=accept chain=forward disabled=yes dst-address-type=!local \
src-address=192.168.156.0/24

(7) WRONG, keep it standard out-interface-list=WAN
It wont be used anyway as your traffic will be source natted when it goes out the remote site wireguard router.
What you have is wrong.
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
out-interface=wireguard1

Summary

VERY CONFUSED SETUP.

1. Provide accurate information in terms of a network diagram many holes.
2. List the requirements more clearly without talking about equipment or config.
what you want users to be able to do.

The setup is confusing because it's not a setup... I can change everything here and even the keys if needed on both sides.
MT in my case will be client wireguard router device (as holvoetn said, some sort of a road warrior client so wherever I plug it in, it makes a secure connection home).
All devices (phone for example, over wifi) connected to MT should use MT as gateway for reaching the endpoint.
The endpoint has a dynamic public IP address.

Eventually, I will try to replicate this on the SXT LTE, yes... and my ISP uses CGNAT. Endpoint has public IP without CGNAT, but it's dynamic (therefore the DDNS).

Here /ip route print

Flags: D - DYNAMIC; A - ACTIVE; c, s, d, y - COPY; + - ECMP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
# DST-ADDRESS GATEWAY DISTANCE
0 As+ 0.0.0.0/0 wireguard1 1
DAd+ 0.0.0.0/0 192.168.88.1 1
DAc 10.0.1.2/32 wireguard1 0
DAc 192.168.88.0/24 internet 0
DAc 192.168.156.0/24 bridge1 0


Removed as anav said and replaced most of the stuff like said.

New file attached with hide-sensitive

I got an SXT LTE setup like that way down in France (though I do not route ALL traffic home).
Also mAP and mAP Lite as road warrior devices. Even there, not everything goes home (only towards my local subnet) but that's changed with only one entry

Just wondering ... how did you determine the tunnel was being set up ?
Did you see traffic flowing up AND down ? Because the nature of this interface is that it will ALWAYS show (some) TX traffic. It's only when you see something coming back that you know it has been properly activated.

That traceroute image you showed can not be right, I think.
If the tunnel works, you should not be able to see the intermediate hops because they would not be visible.
You're IN the tunnel if it works so you can only have a look at the other end, nothing in between.

About those routes:
Change this one:
/ip dhcp-client
add comment=defconf interface=internet

to
/ip dhcp-client
default-route-distance=5 interface=internet

You're never reaching the wireguard option of your routes since the default route to go out has a lower distance.

We are onto something. Without changing the default DHCP route distance, now the traffic goes over wireguard, but it looks like it's dropping tons of packets. Even the traceroute from the client device connected to MT shows working traceroute, but every 10th time it gets up to 3-4th hop.

When changing dhcp route distance, it doesn't goes over wg at all (huh?). Obviously something here is happening.

That traceroute image you showed can not be right, I think.
If the tunnel works, you should not be able to see the intermediate hops because they would not be visible.
You're IN the tunnel if it works so you can only have a look at the other end, nothing in between.

It was a traceroute from my client MT to my home public IP, not anything on the network where the wireguard server is. So it is logical that it shows first wireguard server as first hop, then the router behind wg server, then all the hops back to my home ip.

Ping the other side of the tunnel's WG-IP address.
I always use that as reference.

That is funny. Ping doesn't work... so the client has 10.0.1.2 and the server has 10.0.1.1 and ping to 10.0.1.1 doesn't go. BUT, when doing a traceroute, it shows 10.0.1.1 as first hop.

Your explanation is as flaky as your setup, and your unwillingness to cooperate will unnecessarily lengthen the resolution to your issues. Good thing holvoeten is patient.
Good luck. Moving on.

Everything works. Policy routing was wrong. Wrong interface selected. Can't believe that was it. The interface there needed to be bridge instead of wireguard.

Glad you got it sorted out.