OK. So if connecting two routers over WG, then you need to make sure that both have different LAN subnets? Yes?
So if I use 192.168.1.0/24 in one LAN, then I need to use something like 192.168.2.0/24 or another subnet that is NOT 192.168.1.0/24.
Do I understand that correctly?
In terms of processing as stated above by others, The wireguard protocol or routing process should be considered in the TWO DIRECTIONS.
INCOMING (FILTERING) - Traffic arriving at ones router through the wg tunnel and goes through a wg filtering process which basically amounts to checking the allowed addresses associated with traffic coming from the specific peer, to either allow or drop the incoming packets. If the incoming source address, exists for that peer, then the traffic is permitted to exit the tunnel and is now un-encrypted and faces the routers own firewall rules ( allowed to reach router services - input chain, or allowed to LAN subnets - forward chain ) or not and is dropped.
OUTGOING (MATCHING AND FILTERING) - Traffic leaving ones router, aka traffic originated locally, first has to meet local firewall rules, is the source address allowed to enter the tunnel. If so and a route exists pushing the traffic into the tunnel, then the Wireguard processing takes over (the crypto processing) in this case its not just straight filtering, its MATCHING and FILTERING. In this case the router starting at the first peer, looks to see if the destination address matches any of the peers, when and if it does, it then selects the peer for then transmitting of the traffic.
One should intuitively see that OUTGOING traffic processing will not work properly (on a wg server router for handshake, aka multiple client peers) if
a. one has duplicate subnets in the allowed addresses of peers on the router
b. has any entry of 0.0.0.0/0 on a single client
Ex. lets say you have 5 client peers, and the first one on the list has allowed address of 0.0.0.0/0
This effectively means ALL originating traffic on the router, heading for peers 2-5, will never be used.
Traffic will go only through peer1, and any traffic intended for other than peer1 will be dropped when it reaches the client peer.
+++++++++++++++++++++++++++++++++++++
To answer your question. YES. If you have the opportunity to control at least one end of a wireguard tunnel, it would be smart to avoid any duplication as then there would be conflicts.
Now, of late MT is providing some unique way when dealing with wireguard when one has no control over networks but has to admin them. So clients provide setups with such conflicts.
MT routers can now deal with that using wireguard over vrf but its beyond my scope of knowledge............
You can still make it works if the LANs on both sides use the same 192.168.1.0/24 subnet, but some NAT is needed (a couple of netmap rules on each side).
On router of site #1:
Add route in /ip route for dummy destination 172.20.2.0/24 using the WG interface as gateway (the .2. is for Site #2).
/ip route
add dst-address=172.20.2.0/24 gateway=wg-interface-name
In the WG peer representing the site #2, add 172.20.2.0/24 to allowed-address.
Add a SRCNAT netmap rule, that maps source addresses from the 192.168.1.0/24 range to the 172.20.1.0/24 range (it's .1. for Site #1).
/ip firewall nat
add chain=srcnat action=netmap out-interface=wg-interface-name \
dst-address=172.20.2.0/24 src-address=192.168.1.0/24 to-addresses=172.20.1.0/24
Add a DSTNAT netmap rule, that maps destination addresses from the 172.20.1.0/24 range (it's .1. for Site #1) to the 192.168.1.0/24 range.
/ip firewall nat
add chain=dstnat action=netmap in-interface=wg-interface-name \
dst-address=172.20.1.0/24 src-address=172.20.2.0/24 to-addresses=192.168.1.0/24
On router of site #2:
Add route in /ip route for dummy destination 172.20.1.0/24 using the WG interface as gateway (the .1. is for Site #1).
/ip route
add dst-address=172.20.1.0/24 gateway=wg-interface-name
In the WG peer representing the site #1, add 172.20.1.0/24 to allowed-address.
Add a SRCNAT netmap rule, that maps source addresses from the 192.168.1.0/24 range to the172.20.2.0/24 range (it's .2. for Site #2).
/ip firewall nat
add chain=srcnat action=netmap out-interface=wg-interface-name \
dst-address=172.20.1.0/24 src-address=192.168.1.0/24 to-addresses=172.20.2.0/24
Add a DSTNAT netmap rule, that maps destination addresses from the 172.20.2.0/24 range (it's .2. for Site #2) to the 192.168.1.0/24 range.
/ip firewall nat
add chain=dstnat action=netmap in-interface=wg-interface-name \
dst-address=172.20.2.0/24 src-address=172.20.1.0/24 to-addresses=192.168.1.0/24
Now the devices in the LAN of Site #1 will use the destination address 172.20.2.X to talk to the device 192.168.1.X on Site #2.
Similarly, the devices in the LAN of Site #2 can use the destination address 172.20.1.Y to talk to device 192.168.1.Y of Site #1.
Cool! Thank you. This is really helpful. I appreciate all the education here.
Thanks, everyone for the help! Right now I have 3 routers (my two kids and my travel router with me as I’m remote) connected to my MT router along with my two phones. All on the back to home interface.
I now understand the Wireguard settings a whole lot better!!
Keep in mind, that MTs back to home functionality is a work in progress. They keep nibbling away at corners making it better, more intuitive and flexible. I still have some issues trying to use it at times, so you are doing great!
OK. I have another question….
One of the problems with the back-to-home implementation that Wireguard uses, is that if you attempt to edit any of the peers added by the phone app, it turns ALL of the peers on the back to home interface into dynamic entries whether you want it to do that or not.
So I decided to try creating a separate WG interface for anything I manually create on the MikroTik and leave BTH strictly for portable devices that use the BTH app.
Do I need to use a different IP subnet for each WG interface? I ended up using the same subnet (just a different listen port) and I think I messed some things up.
I can no longer access any of my remotely connected devices on either interface. I’ve tried going through my settings (IPs, Firewall, etc) and duplicating anything that is in there for the Back to Home interface. But it’s still not working.
I have a feeling each interface should have its own IP subnet - yes? Or have I possibly got something else wrong?
You should use different subnets when setting /ip address for different WireGuard interfaces. The reason is when you add those /ip address entries, connected routes (they have the C flag in the table) are added to the routing table, with destination equals to the network-address/prefix-length, and gateway is the interface. The route is used when the router needs to send or forward packets with destination addresses in that range. The router will then know which WG interface to choose to handle the following steps.
If you add the same subnet to the two different WG interfaces, there will be two routes in the routing table with the same destination (the subnet) but with two different gateways (the two WG interfaces). Because they have the same distance (distance value of connected route) the two routes will form a ECMP group (in the routing table they have a + sign as flag), a kind of load balancing, and depending on the hashing of the source and destination addresses, packets will sometimes be put on one interface and sometimes on the other, even if that WG interface does not have the right peer configuration.
So, to avoid problems, if you have separate WG interfaces, assign separate, non -overlapping /ip address entries to them.
OK, here’s my problem that I’m trying to solve.
As I explained, I messed up and have two WG interfaces with the same IP range. I connected to one of my remote devices and moved it to the new interface. But now I can’t get to it. It’s there - it’s connected but I can’t route to it probably because it shares the address pool with the back to home interface.
So I thought I would temporarily change the IP address pool of the back to home interface, then hopefully be able to connect to my remote site - update its IP to what I want to use for the new interface, then change it on the interface on the MT and off we go. But I can’t change the IP range of the back to home interface - it’s all dynamic. And you can’t change it in the app on the phone either. Seems like MT forces you to use 192.168.216.0 no matter what you do. And I don’t know if they have made changes recently but I know previously I could connect to the MT from the phone app and it wouldn’t automatically take control over all back to home peers. You had to actually edit a peer on the phone. But now it just takes them over. You can’t even set the peer IP address in the Back to Home app any more. It’s all automatic. Nothing can be edited on either end.
I don’t know if any of this stuff can be edited/disable via CLI but I’m not very good at the MT CLI (yeah - I know - I should be).
I really don’t like what they have done to BTH with the inability to edit anything at either end…
I’m open to suggestions on how I can get traffic routed temporarily to my new interface so I can update the client on the other end.
If you have a public IP, or an upstream router with a public IP that can be port forwarded, then the recommendation is dont use BTH. Some do anyway because it conveniently creates an export file......
But the flexibility as you are finding out is limited. I have asked MT to move some of that BTH functionality to the main Wireguard interface to provide that kind of useful functionality.......... still waiting LOL.
There is no problem running both, but as noted, any native wg interface on the router should be completely separate. One cannot change the dynamic rules of the BTH firewall rules created as they are just that dynamic. Last time I checked, I could not even move their position or order in fw rules, very annoying.
Also annoying, cannot export a file which includes the current dynamic settings.
In terms of your issue, assuming BTH is not the problem or at least still works and should be then just left alone.
The easiest fix I can think of is simply do this.
192.168.216 etc................
THus keep the original one for the moment and create a second address for the same interface
/ip address
add address=10.20.30.1/24 interface=WG-Interface-Name network=10.20.30.0
Then go ahead and move your NON BTH devices to this address schema.
First start on the router where you define the peers.
so if you have existing peers for these clients
add allowed address=192.168.16.X interface=WG-Interface-Name public-key=X,Y,Z
Then simply edit it to
add allowed address=10.20.30.X interface=WG-Inteface-Name public-key=X,Y,Z
++++++++++++++++++++++++++
At the client END.
ensure the endpoint address points to the public IP
ensure the endpoint port points to the one you created manually for your wireguard interface, and ensure different from any BTH assigned port.
Adjust address schema so client goes TO
WG Interface=clientA-Interface
Address=10.20.30.X
Peer Settings
add address=0.0.0.0/0 or 10.20.30.0/24,subnetA,subnetB
endpoint-port=domainname for public IP, endpoint-port=as needed, public-key (no change), persistent-keep-alive=30s
Now ensure your router interface setting has a different port than BTH and ensure your client port is modified to that
Now you can remove the IP address you manually created that overlaps with BTH
So the challenge is I have a remote client that I don’t have access to except remotely. It’s connected right now to the new interface but I can’t access it which I am assuming is a routing issue. It’s on the 192.168.216.0 network.
I need to just solve my routing problem to get into that router, update the WG information to the new IP scheme and then I can undo whatever temporary settings had to be made.
Does that make sense?
Okay, you are working from an MT router, what router is at the remote end??
I am thinking setting up a quick and dirty temp SSTP connection.........
I have zero physical access to that router right now. I need to set routing with the connection I have to it right now. It’s not an MT router.
I thought you had remote access to the other router???
If not, dont think I can help further. You need to be able to configure the other end
So remote into the other end and perhaps create another wireguard interface or something.
No. I don’t have remote access to the other router right now. That’s my point. It is connected to my MT over Wireguard.
I have a connection. I don’t have the routing into that connection. That’s what I need help making.
Would it work to completely delete all BTH stuff and the interface itself? Not sure if I can even do that as it is created dynamically
Busy for the next hour or so, but think about maybe doing a I live session over anydesk so I can see what you are dealing with.
That’s possible. I appreciate it.
Here’s most of my config file. I took out some stuff related to my VLANs and other things which aren’t germane to this discussion. It’s mostly there though…
Oct2525.rsc (16.4 KB)