What a shame that MikroTik did not integrate WireGuard completely—- by taking advantage of every aspect provided by its creator. Every Linux disto that includes WireGuard takes complete advantage of the Donenfeld creation except RoS. Yes, the Donenfeld wg tools that for example effectively generate routes automatically ….
I don’t think you exactly know what you’re talking about. RouterOS has everything except high level tool that processes WG config file. Same way RouterOS doesn’t take standard OpenVPN config files. But you don’t need that, the config is just entered differently, there’s nothing missing (for WG, OpenVPN in RouterOS is missing some features).
Edit: They could perhaps add an option to automatically create routes from peers’ allowed-address, it wouldn’t be universal thing, but it could help someone. I personally think it’s not too important, but maybe…
Im putting this on a poster"
SOB SAYS “They could add an option to automatically create routes from peers’ allowed-address” to MIMIC the Donenfield Creation. 
)))))
Let me counter Mozerd, by stating, that wanton MASS ip route creation from Allowed IPs, is not as bad as MASS MURDER, but it is a minefield of problems in the hands of the beginner. It may work on a very simple configuration (like a single smart device) but I am thinking it may get less and less useful as the number of peers and multiple addresses within a peer start adding up.
In any case, my concerns may be groundless, especially seeing its wide use in many other linux based programs, but AS LONG AS I dont have to create an IP address for the Wireguard Interface to create such Routes, both SOB and I will be like two pigs playing in the mud!!
…which is the part you also need to add things WILL get dirty.
@anav: Don’t get overexcited, the word is routes, not your “original invention” with addresses.
And on one hand, why not, if you have just some simple config where allowed addresses are the same as you want to route, it could be useful shortcut (something like /interface/wireguard/peers/add allowed-address=10.0.0.0/8 add-routes=yes, and it would create dynamic route to 10.0.0.0/8).
Other clients like wg-quick have it as default behaviour, but even there it’s not hardcoded, you can optionally turn it off, or choose other than main routing table. RouterOS has slightly different and more flexible approach, it lets you add required routes manually, with whatever properties you need, different routing tables, distances (you could have e.g. two WG tunnels as failover), anything you like.
I understand how at first sight WG in RouterOS may seem complicated when you’re used to something else. Other clients just take one config file, where everything is together, keys, peers, addresses, routes, and then you just run one magic command and it configures everything. In RouterOS you have to enter these things in several different places. But you can’t compare this with running the magic command, the thing you should compare it to is writing the config file. And there’s not much difference there.
A different thread has my interest
in terms of having multiple peers on the same interface and with a coordinated Wireguard Interface subnet.
Chap has an MT device behind CGNAT, behind the MT he has an IP camera he wants to access. He has a VPS server (unbuntu) that can run wireguard and he plans on connecting the MT to the VPS. He currently accesses the vps server via laptop or smart phone.
[ Discussion but not what I want to explore in any depth - The part I didnt get was his part about port forwarding traffic from the VPS to the MT over wireguard. I missed the fact that his plan was NOT to wireguard into the VPS from mobile devices (laptop or smartphone). Does this mean that most people access their VPS server without VPN ?? ]
Where I want to go, is a full wireguard end to end connection from mobile device to IP camera.
Is there only option A, or will option B also work and if so how?
A. (two wg interfaces at VPS) → have the remote mobile devices come in to vps on one tunnel and then use a second tunnel between the VPS and MT
B. (one wg interface at VPS) → have all devices on the same wireguard interface… this seems the most efficient BUT how would this actually work… Could a mobile laptop connect directly to the MT or is what mozerd indicates a clue to NO WAY (wg is only peer to peer, not peer to multi-peer) ?
A. is clean to me. I can visualize what goes on with the traffic…
Traffic from remote mobile device arrives at VPS via wg, exits the tunnel.
Firewall rules allow this traffic to reach second tunnel
IP route directs this traffic to second tunnel
I just have to make sure the return path also exists… not to hard.
B. NOT A FRIGGEN CLUE.
++++++++++++++++++++++++++
That’s not what @mozerd is barking at.
The real difference between client-server and peer-peer is that in client-server there’s sever listening for connections and it’s always client that initiates the connection. In peer-peer both parties are listening for connections and any of them can initiate the connection.
And this doesn’t say anything about peer-multipeer … one would have to test, but I guess for the peer-peer part, peer-multipeer is exactly the same.
As to the claim that @mozerd is making real loud … that wireguard is not client-server. Well, it can be. It is possible to configure WG in peers section without endpoint-address … in this case local end-point “downgrades” into server because it doesn’t know how to initiate the connection, it has to wait for remote peer to establish the connection (which makes remote peer a client).
But after the tunnel is up&running (which is kinda moot with UDP being used as “back-end” transport protocol), there’s no difference between client-server and peer-peer topology … the tunnel is open and traffic flows both ways.
This post doesn’t answer to question by @anav, however: it seems like peers, configured via same WG interface, can not communicate directly (which is the way I’d want it done, a hub has to have control over what traffic passes any of links), all packets arriving from WG peers have to exit the WG interface and then it’s up to L3 mechanisms to deal with packets (and optionally push them back to WG interface where crypto-routing takes over). In this regard, it’s similar to using multiple WG interfaces. My explanation is based on this article (similar question, working solution clarifies a lot).
Okay mkx, I thought that was indeed the case where one needs two distinct tunnels to RELAY traffic in this way and that having all the peers on the same WG interface IS NOT capable of relay.
Good to know!.
So why is the chap doing port forwarding from VPS to MT device? Is it because most people https into the VPS device ( then user name and password) and that is good enough for security??
One tunnel is enough:
Server:
- IP 192.168.0.1/24
- Camera peer, allowed IPs 192.168.0.10/32
- Dstnat to 192.168.0.10 (for public access without WG)
- Client peer, allowed IPs 192.168.0.20/32
Camera:
- IP 192.168.0.10/24
- Server peer, allowed IPs 0.0.0.0/0 (to cover access from internet)
- Alternative default route via WG (for access from internet)
Client:
- IP 192.168.0.20/24
- Server peer, allowed IPs IP 192.168.0.0/24
The Author is Vladimír Záhradník .... my type of tech guy 
In WireGuard, there is no client-server relationship. WireGuard introduces a concept of peers, which are interconnected clients, and by definition, there is no superior or inferior peer.
To establish connectivity, you need to ensure the following:
On each peer, create a WireGuard interface and assign an IP address to it with the ip tool. It’s an address inside a VPN network bound to the peer forever
On each peer generate a private key using the wg tool and assign it to the WireGuard interface
Derive a public key, again with the wg tool, and add it to all other peers you want to communicate. WireGuard doesn’t specify how to exchange the keys. I opened an SSH session on each device and copied them over manually
Optionally, tell each peer how to reach other peers by specifying a public IP (or domain) and a port. Not all peers need to know how to reach others, as long as others know how to reach them; you’ll see later
@mozerd: The part you keep missing is that while WG may be peer-to-peer “at heart”, if you have peer behind NAT and it can’t accept incoming connections, such peer is clearly limited. If you’re going to have all such peers, it won’t work at all, because they won’t be able to connect to each other (without some additional tricks like e.g. your favourite Tailscale does). And if you’re going to have exactly one that can accept incoming connections and all others will be connecting to it, it’s clearly client-server behaviour.
@Sob … I believe you are brilliant … as is mkx … and anav is very smart
If its Pure WG Lets not call it C/S … lets call it a communication relay …
behave like a server Peer relaying to a client Peer …
certainly looks like C/S but its still WG-PeerA to WG-PeerC to WG-PeerB …
Yep, Your One Tunnel is enough is right on the money … very nice 4sure
Okay I will bite, but will try to explain it so that is understandable vice sob cryptic short form!
Also will ignore the public access dstnat bit, as the MT is behind another router and cannot forward ports 
oops I see you mean the Dst NAT at the VPS… okay I get it… but will leave that till the end, it confuses my train of thought LOL
VPS server wg port 12122, fixed IP 24.233.45.15
Step1: create wireguard coordinated subnet
VPS linuxspeak=192.168.0.1/24 interface=wg0
MT IP address=192.168.0.10/24 interface=wg-MT { camera resides off this device Ip address local is 10.10.10.50/32 }
Laptop Address=192.168.0.20/32
Requirement: Laptop to reach camera via Wireguard.
Solution (so sob says):
Wireguard at Mobile Laptop
Allowed IPs=192.168.0.0/24 { allows one to ping both VPS server and MT remote client }, 10.10.10.50/32 { camera IP destination address (at MT device) }
[Note: if internet access was involved the only allowed IP required would be 0.0.0.0/0]
Wireguard settings at VPS
Peer MT Allowed IPs - 192.168.0.10/32 { allows pinging from MT },
Peer Laptop Allowed IPs - 192.168.0.20/32 { allows pinging and all incoming traffic from laptop }
Wireguard settings at MT (camera)
Peer Server Allowed IPs - 192.168.0.1/32 { allows pinging from Server }, 192.168.0.20/32 {allows traffic from laptop to exit tunnel at MT }
IP Routes.
MT DEVICE
(dac) dst-address=192.168.0.0/24 gwy=wg-MT table=main ( allows outbound pinging to VPS server and return pings from VPS or laptop)
dst=address=192.168.0.20 gwy=wg-MT table=main NOT REQUIRED (return traffic from camera covered by DAC rule??? ***
VPS SERVER
(dac) 192.168.0.0/24 gwy=wg-MT table=main ( allows outbound pinging to MT and returning pings from MT or laptop )
******* similarly return traffic from MT to laptop moves transparently through VPS due to the DAC rule.???
++++++++++++++++++++++++++++++++++++++++++++++
With only WG to the MT camera and only an external connection from LAPTOP to VPS, then at the VPS we would have to do some dstnat like work.
Since I dont know linux I will couch it in MT forms..
But this is really good for learning too → HOW TO PORT FORWARD THRU a wg tunnel.
add chain=dstnat action=dst-nat in-interface=?? WAN or dst-address=fixed IP of VPS wan connection??
protocol=whatever dst-port=actual cameraport? to-addresses=actual camera local IP or IP of MT wireguard??
If you want direct access to camera’s internal address, then you need 10.10.10.50/32 also here:
And server must also have route to 10.10.10.50/32. Then it’s better to have whole 192.168.0.0/24 as allowed here:
Because if you add another client, you won’t need to touch it. And here:
If you have (dynamic) route to 192.168.0.0/24, you don’t need another route to 192.168.0.20, because the first one includes it. Go play a bit with subnet calculator.
It’s simple port forwarding like any other, on server you’ll have dst-address= and to-addresses can be both 10.10.10.50 and 192.168.0.10. If it’s the latter, then you’ll need additional dstnat on camera’s MT.
[quote=Sob post_id=920437 time=1647879773 user_id=33312]
If you want direct access to camera’s internal address, then you need 10.10.10.50/32 also here
[quote=anav post_id=920417 time=1647875296 user_id=115581]
Wireguard settings at VPS
Peer MT Allowed IPs - 192.168.0.10/32 { allows pinging from MT }, [/quote]
WHY? —> Because in a relay scenario, within the same interface, one MUST still view the traffic from Laptop. after arriving at VPS WG interface, as requiring a valid destination address, for the next leg, although never exiting the wireguard interface? (aka 10.10.10.50/32 is checked as a valid destination address for selection outbound at VPS just as it was for the laptop itself??).
Note that this is exactly what one would do if it were for a separate tunnel (second wireguard interface).
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This I understand, makes sense, and hence why I stated not required and future proofing yes!
This is the one thing I didnt understand!!
Why does the VPS server need a route to 10.10.10.50/32.
IF all the traffic is remaining within wireguard and not exiting the tunnel at VPS, and we are not using a second tunnel…
OR ARE YOU REALLY SAYING, yes the traffic has to EXIT THE TUNNEL and then RENTER the tunnel ???
in which case this would make more sense…
It would act at a way to get traffic to the mT for traffic exiting the tunnel at VPS that came from laptop
dst-address=10.10.10.50/32 gwy=wg0
Not sure if you meant to somehow associate this with 192.168.0.0/24 above??
Why? I see the port forward from VPS into wireguard, but NOT ON the MT.
This seems right! ( assuming its still the laptop requesting the information from the camera and the op still manages to use the same Ip address .20 - not sure how )
VPS Server
add chain=dstnat action=dst-nat dst-address=publicIP-VPS to-address=192.168.0.10
MT
add chain=forward action=accept in-interface=wg-MT source-address=192.168.0.20/32 dst-address=10.10.10.50/32
You can have either what I posted, with only WG subnet (192.168.0.0/24) and anything else behind any peer (your 10.10.10.50) must be handled using srcnat/dstnat, so WG won’t see it. Or if you want to avoid NAT (generally good idea), then it would be:
Server:
- WG IP 192.168.0.1/24
- Camera peer, allowed IPs 192.168.0.10/32, 10.10.10.50/32
- Route to 10.10.10.50
- Dstnat to 10.10.10.50 (for public access without WG)
- Client peer, allowed IPs 192.168.0.20/32
Camera:
- WG IP 192.168.0.10/24
- LAN IP 10.10.10.1/24
- Camera IP 10.10.10.50/24
- Server peer, allowed IPs 0.0.0.0/0 (to cover access from internet; otherwise 192.168.0.0/24 for WG-only access)
- Alternative default route via WG (for access from internet)
Client:
- WG IP 192.168.0.20/24
- Server peer, allowed IPs IP 192.168.0.0/24, 10.10.10.50/32
- Route to 10.10.10.50 (if client is MT, otherwise added automatically by wg-quick and others)
It’s simple routing and WG’s allowed IPs reflect what can be routed.
I’m saying that traffic from client to camera (or back) will have in-interface=WG out-interface=WG on server.
Why do you give the client (mobile device lets say ipad or laptop windows etc) a Wiregurd Address of 192.68.20.20/24 and not 192.168.0.20**/32**
Its just a single device??
I thought that a full /24 was to be used for Devices that have the capacity for multiple subnets for example.