Hi to all,

I am aware this is a silly idea, but apparently it _is_ doable, I just don't know RouterOS well enough particularly wrt routing to get the job done right.

So my scenario: Link between main home LAN A and holiday home LAN B in two different cities

LAN A (192.168.22.0/24) connected to LAN B (192.168.0.0/24) via WireGuard (192.168.2.0/24)
All working well, A can reach B, B can reach A.
Everything working as expected
I love WireGuard.

From LAN, I need to "place" ESXi VM 192.168.22.X (running Unifi Network Controller on Debian/Ubuntu) "on" LAN B with
IP 192.168.0.X so that I can have the VM manage the existing Ubiquiti APs connected to LAN B on IPS 192.168.0.A and 192.168.0.B

I know it's a "bad" idea to place the Unifi VM in LAN A "onto" LAN B, but it is what I need to do (unless someone knows how to tell Unifi Controller
to go look for LAN B via the WG Client on it??)

What I find at the moment is that when trying to get WG client on VM 22.X (LAN A) connected to 0.1 (LAN B) I can establish the connection,
I may even be able to ping the gateway on the other end of the link (depending on which side I am trying to do it from) but the ability to
talk to 0.X (anything) on LAN B when WireGuard client on VM is connected, just isn't working.

Sorry for the roundabout way of describing it.

What I have tried is to use routes (I'm ok at this) and policy based routing (I'm totally new at that) to achieve it, but when I get A to work I
break B and vice versa, so it isn't going to fly.

I did find/read some information about mangling the packets and setting up new routes based on named routing tables, but I'm not experienced
enough to understand what I am doing and why, given the documentation I have found.

Anybody willing to provide me some guidance as to:
1) Is this achievable (even though it would be better to do it the "right" way)
and
2) Provide me with a step by step breakdown of the underlying principles I'm not aware of when it comes to this?
or
3) Make alternative recommendations even if it includes somehow telling the Unifi Controller to go "look" for LAN B 0.X via client interface tunnel WG connected on 2.X

ps : I know I can re-enroll/adopt the Unifi equipment and connect them to the controller on LAN A easy enough, but I don't
have technically capable hands on-prem at LAN B that could do this, and LAN B is several thousand KMs away.

Thanks for the energy, please be kind

Is there some sort of discovery protocol in play here where the unifi controller or APs broadcast to find each other on the same subnet ??
Or do you tell the controller the IP addresses of the AP.

Zerotier is a level 2 construct that would support putting the unifi controller and two APs in the same layer 2 network.

Wireguard and EOIP on top can used as well for the same purpose.
Already used it before, discovery works perfect then.

SOLUTION METHOD ONE - EOIP OVER WIREGUARD
a. create wireguard connectivity as per normal and then
b. create the EOIP tunnel within the WG tunnel ( EOIP never concerns its self ever with local WANIPs at either end )
c. modify configs to avoid L2 conflicts with identical subnets.

a. Setup the WG

/MT Device One info
/interface wireguard
listening port 15551 mtu=1420 name=wireguard-home
/interface wireguard peers
add allowed-address=192.168.50.2 interface=wireguard-home public-key="---" comment=Router2
add allowed address=192.168.50.3 interface=wireguard-home public0key="---" comment=remoteAdmin
/ip address
add address=192.168.50.1/24 interface=wireguard-home

/MT Device Two
/interface wireguard
listening port 10771 mtu=1420 name=wireguard-client
/interface wireguard peers
add allowed-address=192.168.50.0/24 endpoint-address=mynetnameMTDEVICEONE endpoint-port=15551 \
interface=wireguard-client public-key="..." persistant keep-alive=35sec
/ip address
add address=192.168.50.2/24 interface=wireguard-client

Setup EIOP tunnel over wireguard.

R1 - VLANS 10,20,30 are on the bridge vlan20 is the subnet unifi controller is on.
R2 - VLANS 5,20,40 are on the bridge, VLAN 20 is the same subnet and where the APs exist.
Both Routers provide DHCP on the subnets.

Router ONE,
eoip-to-TWO
remote address= 192.168.50.2
local address= 192.168.50.1
tunnel ID= 321

Router TWO
eoip-to-ONE
remote address= 192.168.50.1
local address= 192.168.50.2
tunnel ID= 321

Router One

/interface bridge ports
add bridge=bridge interface=eoip-to-TWO pvid=20
/interface bridge vlan
add bridge=bridge tagged=bridge untagged=eiop-to-TWO vlan-ids=20

Note: Tagged or Untagged works but if one can save the overhead of 4 bytes, one pays less carbon tax.

Router Two
/interface bridge ports
add bridge=bridge interface=eoip-to-ONE pvid=20
/interface bridge vlan
add bridge=bridge tagged=bridge untagged=eiop-to-ONE vlan-ids=20

c. PROBLEM: HOW TO DECONFLICT SAME L2 SUBNET in TWO ROUTERS.

Solution Part 1: VLAN20
R1 ip pool = 192.169.2.2-192.168.2.100
R1 ip address = 192.168.2.1 interface=vlan20 network=192.168.2.0
R2 ip pool = 192.169.2.120-192.168.2.220
R2 ip address = 192.168.2.254 interface=vlan20 network=192.168.2.0

Solution Part 2: Bridge
R1 /interface bridge --> name=bridge vlan-filtering=yes dhcp-snooping=yes
R1 /interface bridge ports ---> add bridge=bridge interface=local port/wlan trusted=yes
R1 /interface bridge ports ---> add bridge=bridge interface=eoip-to-TWO trusted=no
R2 /interface bridge --> name=bridge vlan-filtering=yes dhcp-snooping=yes
R2 /interface bridge ports ---> add bridge=bridge interface=local port/wlan trusted=yes
R2 /interface bridge ports ---> add bridge=bridge interface=eoip-to-ONE trusted=no

In effect, we ensure different address and gateway for the same subnet/vlan so that there is no issue with which Router is used for internet traffic.
We ensure that we keep the internet traffic of the local subnet via the local WAN.
The bridge settings ensure that there is no possibility of conflict with DHCP assignments between the two subnets connected over the EOIP tunnel.

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

In a routed tunnel (Wireguard or other) ... insert a L2 tunnel ...

EoIP or MPLS/VPLS for lower CPU loads than EoIP, or even PPTP/SSTP/L2TP with BCP bridging.
BCP Is documented for PPTP, but is there in SSTP, PPTP and L2TP
https://wiki.mikrotik.com/wiki/Manual:B ... _bridging)
And VXLAN should be checked in ROS V7 as 4th possibility

Zerotier would provide the routed VPN , even passing NAT in reverse direction with STUN or TURN, and give the L2 connection.

I have the same problem, but I want to get the ip of WireGuard Peer in home network, when I change masquerade in NAT, I can't access Lan network. Can i get any advice? Thanks

WG uses L3 routing, period. If ya need Layer2 look to bridging, and @bpwl list the various options.

If the issue is only the Unifi's controller... AFAIK it supports both a L2 and L3 adoption method. For WG, you should be use some DNS or DHCP Option 43 to have the "Home B" find a the Unify in "Home A", using only Layer 3.

Well what format for the option 43 value does MT accept...........

192;168;168;50
or
01;04;192;168;168;50

or something else because my attempts show popup message "couldnt add new dhcp option, wrong data type! (6)"

ahh convert to hex SHEESH

SOLUTION METHOD TWO USE DHCP OPTION 43
a. create wireguard connectivity as per normal and then
b. create the DHCP Option settings on R2 for the unifi Access Points.
c. modify configs to allow Access Points via Wireguard (L3 traffic) to route to Unific controller IP.

a. Setup WG as per usual.

/MT Device One info
/interface wireguard
listening port 15551 mtu=1420 name=wireguard-home
/interface wireguard peers
add allowed-address=192.168.50.2, 192.168.168.0/24 interface=wireguard-home public-key="---" comment=Router2
add allowed address=192.168.50.3 interface=wireguard-home public0key="---" comment=remoteAdmin
/ip address
add address=192.168.50.1/24 interface=wireguard-home

/MT Device Two
/interface wireguard
listening port 10771 mtu=1420 name=wireguard-client
/interface wireguard peers
add allowed-address=192.168.50.0/24, 10.10.10.0/24 endpoint-address=mynetnameMTDEVICEONE endpoint-port=15551 \
interface=wireguard-client public-key="..." persistant keep-alive=35sec
/ip address
add address=192.168.50.2/24 interface=wireguard-client

b. Now that wireguard is setup lets SETUP Dhcp options for R2

Router 1, LAN A - 10.10.10.0/24, unifi controller is 10.10.10.15
Router 2, LAN B - 192.168.168.1/24, AP1 192.168.168.5, AP2 192.168.168.20

DHCP server settings for Router 2 LANB
Create an OPTION , call it Option UNIFI
select code 43
select unifi IP address 10.10.10.15 we need to add 0104 in front of it according to searches.
so enter this for the value entry----> 0x0104'10.10.10.15'
Hit Apply and OK, The MT router will convert this to HEX and a raw value!!

Then Go to DHCP NETWORKS.
select LANB
select tab DHCP Options
select UNIFI.

Now the dhcp server will provide the AP with a local IP (offer) and tell the AP the controlling device IP address........
The APs will now send traffic to that IP and we must provide a path there.

c. Now lets ensure that path exits.

Hence in R2 allowed IPs, for peer of R1, we added 10.10.10.0/24


Hence in R2 we add a route
/ip route
add dst=10.10.10/24 gwy=WG-Client table=main

Hence in R2 we add firewall rule.......
add chain=forward action=accept in-interface=LANB out-interface=WG-Client src-address-list=UBI-APs

Now when the APs attempt to reach the destination of the unif controller, the routing there will be found by the router to be the wg tunnel, firewall rules will allow it, and the wireguard rules will match the traffic to the peer of R1 and send it on its way.

At R1 we need to ensure allowed IPs for peer router2 include 192.168.168.0/24
and thus will be filtered/accepted and allowed to exit the tunnel upon arrival at R1

At R1 we need corresponding firewall rule
add action=accept chain=forward in-interface=WG-Server dst-address=LANA src-address=External_APs
and thus the traffic will allowed to go to the unif controller

Finally at R1 we need to ensure a router back into the tunnel for said traffic.
add dst=address=192.168.168.0/24 gwy=WG-Server table=main

SOLUTION METHOD 3 - VXLAN OVER WIREGUARD TUNNEL
a. create wireguard connectivity as per normal and then
b. create the VXLAN tunnel within the WG tunnel ( vxlan never concerns its self with local WANIPs at either end )
c. modify configs to avoid L2 conflicts with identical subnets.

For those not familiar with VxLAN, it's an tunneling protocol which wraps layer 2 frame into a UDP packet at layer 3.

Diagram courtesy of Charles D.
... ...
SCENARIO, Span subnet like EOIP over two separate locations.

Facts:
VLAN B - LANB on R1 where unifB controller resides and LANB on R2 where two unifi APs reside AP1-B and AP2-B
It is thought (but not verified) that the underlying Network (in this case Wireguard) should have a higher MTU (min 1522, we will use 1550)

SO in our example we are going to create one vxlan tunnel between VLAN B on R1 to VLAN B on R2.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


a. setup the wg tunnel

/MT Device One info
/interface wireguard
listening port 15551 mtu=1550 name=wireguard-home
/interface wireguard peers
add allowed-address=192.168.50.2, interface=wireguard-home public-key="---" comment=Router2
add allowed address=192.168.50.3 interface=wireguard-home public0key="---" comment=remoteAdmin
/ip address
add address=192.168.50.1/24 interface=wireguard-home

/MT Device Two
/interface wireguard
listening port 10771 mtu=1550 name=wireguard-client
/interface wireguard peers
add allowed-address=192.168.50.0/24, endpoint-address=mynetnameMTDEVICEONE endpoint-port=15551 \
interface=wireguard-client public-key="..." persistant keep-alive=35sec
/ip address
add address=192.168.50.2/24 interface=wireguard-client

b. Now lets construct the vxlan tunnel

R1 VLAN B - 192.168.2.0/24 , unifi controller = 192.168.2.15,
R2 VLAN B - 192.168.2.0/24 , unifi APs AP1-B = 192.168.2.25 AP2-B = 192.168.2.35

VLANx Settings

Step1: Assign vxlan interface name.
R1: Interface name=ConrollerB
R2: Interface name=AP-B

Step2: Allocate VTEP to the underlying structure
R1: VTEP --> interface=ControllerB remoteIP=192.168.50.2 { since the remote IP wireguard address of R2 is 50.2 }
R2: VTEP --> interface=AP-B remoteIP=192.168.50.1 { since the remote IP wireguard address of R1 is 50.1 }

Step3: Assign vxlan parameters as required. The first iteration of this solution will be to span the same subnet.
R1 (interface ControllerB) --> vni=1001 port=9472
R2 (interface AP-B) --> vni=1001 port=9472

Add both vxlan interfaces to the single bridge on each router and connect/associate to the applicable VLAN interface.
R1
/interface bridge port
add bridge=bridge interface=ControllerB pvid=20
/interface bridge vlan
add bridge=bridge tagged=bridge untagged=ControllerB vlan-ids=20

Note: Tagged or Untagged works but if one can save the overhead of 4 bytes, one pays less carbon tax.

R2
/interface bridge port
add bridge=bridge interface=AP-B pvid=20
/interface bridge vlan
add bridge=bridge tagged=bridge untagged=AP-B vlan-ids=20

c. PROBLEM: HOW TO DECONFLICT SAME L2 SUBNET in TWO ROUTERS.

Solution Part 1: VLAN20
R1 ip pool = 192.169.2.2-192.168.2.100
R1 ip address = 192.168.2.1 interface=vlan20 network=192.168.2.0
R2 ip pool = 192.169.2.120-192.168.2.220
R2 ip address = 192.168.2.254 interface=vlan20 network=192.168.2.0

Solution Part 2: Bridge
R1 /interface bridge --> name=bridge vlan-filtering=yes dhcp-snooping=yes
R1 /interface bridge ports ---> add bridge=bridge interface=local port/wlan trusted=yes
R1 /interface bridge ports ---> add bridge=bridge interface=Controller-B trusted=no
R2 /interface bridge --> name=bridge vlan-filtering=yes dhcp-snooping=yes
R2 /interface bridge ports ---> add bridge=bridge interface=local port/wlan trusted=yes
R2 /interface bridge ports ---> add bridge=bridge interface=AP-B trusted=no

In effect, we ensure different address and gateway for the same subnet/vlan so that there is no issue with which Router is used for internet traffic.
We ensure that we keep the internet traffic of the local subnet via the local WAN.
The bridge settings ensure that there is no possibility of conflict with DHCP assignments between the two subnets connected over the vxlan tunnel.

@AMMO looks allright??

I'm more a theory guy here. I haven't used UBNT much, but it does support using Layer 3 discovery – which is for sure what you'd want with WG vs adding tunnels-in-tunnels. I also know Option 43 is a PITA for to get right for anything that uses it (e.g. typical VoIP phones).

Since it s "vendor specific", it does need the 0x0104 part, but anything after that is kinda up to UBNT to read, e.g. it's vendor-specific e.g. so maybe '10.10.10.15' will work AFTER 0x0104, or if it needs to be all hexstring 0x01040A0A0A0F - dunno...

It may also use DNS name "unifi", so if that's a static DNS entry in the Mikrotik DNS, that may be all that it takes too. This avoid the whole Option 43 business. A quick Google is unclear... so it likely changes depending on exact what UBNT controller version/type may matter...

Placeholder for VXLAN solution - For those not familiar with VxLAN, it's an tunneling protocol which wraps layer 2 frame into a UDP packet at layer 3.

My main worry is mixing WG with Layer2 tunnels is that MTU is going to crushed between WG and a layer 2 tunnel. VXLAN may be worse of all, since you're adding another UDP layer on top (and likely unneeded since WG can do the routing). Maybe old, but EoIP with IPSec is a pretty simple solution for these Layer2 tunnels.

It doesn't even need ipsec when going over wg.

AMMO, as you can see my EOIP solution is almost there, just need to figure out internet and WAN implications ( which is what I was expecting Holvoe to come in and show me the way..........
The dhcp options solutions should work for unifi....... good to go!
As for vxlan, set WG to 1550, should make it all feasible, still have work to do on this config

If the need is really only a Unifi controller that is in site in LAN A, with some APs in LAN B...the DHCP option (or DNS "unifi") should be all that's needed. The AP will use IP to communicate with LAN A's controller. No tunnel should be needed: the LAN B devices should be able to use the local internet out. So no EoIP or VXLAN should actually be needed.

Now needs are more generic then just Unifi's controller... EoIP over WG make sense*. But any of these bridging approaches have costs, either in additional bandwidth or potential fragmentation. So if the underlying traffic you bridging is still just UDP or TCP, it's kinda a waste. The main case for bridging is actual this whole "device discovery", which may use broadcasts/multicast find other devices. But then all your regular UDP and IP packets get an 50+ byte extra added to every packet, over WG's 50 bytes. Essentially you're carrying ethernet stuff that is just going to get tossed out. Why I suggest pay the price to figure out the stupid Option 43 string, saves 50+ bytes on every packet in the future....

* As a feature request, it be nice if they added similar checkbox for WG in addition to the IPSec one. I only mention IPSec since if you already didn't have WG and want L2 bridging, EoIP+IPsec is dirt simple, the default configuration/firewall already considers this (and IMO less FW changes needed is what make things "easier"). BUT if you already familar with WG (and have V7), totally make sense use EoIP with WG.

IPSEC has no utility in a home environment IMHO. Haters expected LOL......

You missed the point completely, the unif controller and AP are not in the same location and just to make sure you understand, not under the same local router!
How did I manage to glean that from the OP, probably his comment my HOME, and my vacation home,

[...] LAN A and holiday home LAN B in two different cities

LAN A (192.168.22.0/24) connected to LAN B (192.168.0.0/24) via WireGuard (192.168.2.0/24)
All working well, A can reach B, B can reach A.
Everything working as expected
I love WireGuard.

[...]
I know it's a "bad" idea to place the Unifi VM in LAN A "onto" LAN B, but it is what I need to do (unless someone knows how to tell Unifi Controller
to go look for LAN B via the WG Client on it??)

[...]

3) Make alternative recommendations even if it includes somehow telling the Unifi Controller to go "look" for LAN B 0.X via client interface tunnel WG connected on 2.X

[...]

ps : I know I can re-enroll/adopt the Unifi equipment and connect them to the controller on LAN A easy enough, but I don't
have technically capable hands on-prem at LAN B that could do this, and LAN B is several thousand KMs away.

Either DNS or DHCP Option 43 really should all that's needed the OP's option 3). But it the P.S. the confuses me. He reports that LAN A and communicate with LAN B [via WG+IP/Layer3]. The specific routing inside APs in LAN B take, well, that's something's that "controlled" by the Unify in LAN A - so those details matter too.

You missed the point completely, the unif controller and AP are not in the same location and just to make sure you understand, not under the same local router!
How did I manage to glean that from the OP, probably his comment my HOME, and my vacation home,

No I got that, but the site already have WG working.... Unifi can use just L3/IP is the idea. But not familar with the exact mechanics of Unifi, last time I used them was many years ago. But even then the controller could be in another subnet.

See: https://tcpip.wtf/en/unifi-l3-adoption- ... others.htm

sweet link..........

nice @anav well done.

one note, i'm not feeling comfortable to increase the mtu up to 1550, but yes..let see how it goes on my end

R1 (interface ControllerB) --> vni=1001 port=9472
R2 (interface AP-B) --> vni=1001 port=10472

i don't understand this part here,
VNI is unice, so u can't have more than one interface at the same time.

Thanks nichy I will review................... I thought the vni had to be duplicated................ like EOIP code etc.........
Confirmed think of vni as the Group code for all members on the same vxlan.

In terms of the port setting, what I was instructed is that they do not need to be identical, but can be identical, as they only define what port the router is listening on at its end of the vxlan.
The port used for sending is random I guess. In any case I changed the config to show the same port as that seems to cause less confusion.

Also to both EOIP and vxLAN solutions, I have added deconflicting components because we are spanning an L2 network on two different routers.....
This is why the DHCP option method at least for the specific case of unifi devices is superior. Dont have to worry about L2 shenanigans

one note, i'm not feeling comfortable to increase the mtu up to 1550, but yes..let see how it goes on my end

Oh, what a tangled web we weave, when first we practice to deceive

I can't imagine changing WG's MTU is going to help anything – more likely hurt.

Assuming the ISP is using 1500 MTU, likely if cable/fiber (and lower if PPPoE/etc., and much lower if LTE). And LAN is almost certainly using 1500 MTU. You are going to EITHER get fragmentation or a "constrained" MTU on both sides of a bridged LAN. Regardless of if VXLAN or EoIP. e.g. one LAN packet will quickly turn into many packets over the WAN, especially for TCP traffic.

But changing the WG MTU the upwards is likely a very bad idea. WG is the outer tunnel, so you'd get multiple levels of fragmentation with EoIP/VXLAN also getting fragmented if using defaults. If the WAN's WG path isn't 1500 at any point, even the default 1420 for WG may even be too high. For LTE, it be 1348 to avoid WG getting fragmented inside LTE network (assuming LTE is 1428 MTU, YMMV) too.

In theory, the VXLAN MTU should be the WG MTU - 50 bytes for its headers. Now here this is a tricker decision (WG is easy, don't over-drive MTU – set it to match WAN - 80 bytes!). But for the VXLAN MTU, a lower MTU below 1500 is going to cause the entire LAN to use a lower MTU, since VXLAN (or EoIP) is bridged. And a bridge uses lowest MTU of its ports. But it's here where you faced with Hobson's choice Since it's the inner tunnel fragmentation of bridged packets may be less of a problem, than the problems caused by a lower MTU on the entire bridge. So for testing, I'd leaving the default 1500 as the starting point – still get fragmentation but only on the inner traffic and the MTU difference is masked on either end of the bridge.

If you're wondering why I'm harping on the subtle MTU and fragmentation part here, check out this thread:
viewtopic.php?t=192100&hilit=mtu

At the end of the day, fragmentation is a sure-fire way to get a lower speedtest. If you like seeing higher ones, don't make MTU bigger, make it smaller (well, rather, match the upstream network's actual MTU). And a wrong MTU will very likely break some protocols.

Stick to (conspiracy) theories

Reading on the always 100% accurate internet........
"I've tunneled VXLAN over Wireguard on Linux. In my setup, my WAN's MTU was 1500 bytes, and my Wireguard tunnel's MTU was 1550, with the VXLAN's MTU being 1500. Surprisingly, traffic and iperf3 tests going over the VXLAN had much better throughput than traffic going directly over the Wireguard connection. IIRC, over the VXLAN, I was pulling ~800Mbps over the VXLAN/WG setup with iperf3.

Where this would fall apart is if there are firewalls in between that silently drop UDP fragments. In a case like that, it may be necessary to do VXLAN/Wireguard/Wireguard to conceal the fragmented packets with MTUs of 1500/1550/1440 respectively, assuming IPv4 and WAN MTU of 1500. I bet this would come with a significant performance hit though."

Another find -->
"Setting the MTU on the interface is very important. If you aren't familiar with VxLAN, it's basically wrapping a L2 packet inside of a UDP packet. Normally on a physical infrastructure we would increase the L2 MTU of all the infrastructure links to accomodate the larger packets, but sadly I can't change the MTU of all the links between my two sites. So...we increase the MTU of the VPN link it self. WireGuard does a very nice job with managing this, and breaks up the larger packets for us for transmission. A+ WireGuard! ip link set wg-to-b mtu 1600 "

Stick to (conspiracy) theories

Fine line between a soothsayer and a charlatan. But TCP normally hates liars, maybe wireguard and VXLAN are better bullshitters than I know. Curious at your finding.

Or, the WANs involved do have headroom above 1500 and/or offloading helps more than I would have anticipated.

I only make the configs, I have no use for them personally LOL, so have no clue when the rubber meats the road!!

3) Make alternative recommendations even if it includes somehow telling the Unifi Controller to go "look" for LAN B 0.X via client interface tunnel WG connected on 2.X

ps : I know I can re-enroll/adopt the Unifi equipment and connect them to the controller on LAN A easy enough, but I don't
have technically capable hands on-prem at LAN B that could do this, and LAN B is several thousand KMs away.

Thanks for the energy, please be kind

1. Make a DNS entry on the site you want to adopt Unifi stuff in the form unifi.example.domain IN A <IP address of the Unifi controller>
2. Make sure your DHCP-server hands out example.domain to your Unifi stuff as domain suffix
3. Your Unifi stuff will automatically find your controller on the other side of your tunnel if your WG config is sound.

3) Make alternative recommendations even if it includes somehow telling the Unifi Controller to go "look" for LAN B 0.X via client interface tunnel WG connected on 2.X

ps : I know I can re-enroll/adopt the Unifi equipment and connect them to the controller on LAN A easy enough, but I don't
have technically capable hands on-prem at LAN B that could do this, and LAN B is several thousand KMs away.

Thanks for the energy, please be kind

1. Make a DNS entry on the site you want to adopt Unifi stuff in the form unifi.example.domain IN A <IP address of the Unifi controller>
2. Make sure your DHCP-server hands out example.domain to your Unifi stuff as domain suffix
3. Your Unifi stuff will automatically find your controller on the other side of your tunnel if your WG config is sound.

Thanks Marino are you tempting me with OPTION FOUR LOL..........

WINNER WINNER TURKEY DINNER - Marino!

SOLUTION METHOD FOUR - PREFERRED Option USE DNS ONLY
a. create wireguard connectivity as per normal and then
b. create the IP DNS SETTINGS and DHCP SERVER SETTINGS on Router 2.
c. modify configs to allow Access Points via Wireguard (L3 traffic) to route to Unific controller IP.

a. Setup WG as per usual.

/MT Device One info
/interface wireguard
listening port 15551 mtu=1420 name=wireguard-home
/interface wireguard peers
add allowed-address=192.168.50.2, 192.168.168.0/24 interface=wireguard-home public-key="---" comment=Router2
add allowed address=192.168.50.3 interface=wireguard-home public0key="---" comment=remoteAdmin
/ip address
add address=192.168.50.1/24 interface=wireguard-home

/MT Device Two
/interface wireguard
listening port 10771 mtu=1420 name=wireguard-client
/interface wireguard peers
add allowed-address=192.168.50.0/24, 10.10.10.0/24 endpoint-address=mynetnameMTDEVICEONE endpoint-port=15551 \
interface=wireguard-client public-key="..." persistant keep-alive=35sec
/ip address
add address=192.168.50.2/24 interface=wireguard-client

b. Now that wireguard is setup lets SETUP the DHCP and DNS for R2

Router 1, LAN A - 10.10.10.0/24, unifi controller is 10.10.10.15
Router 2, LAN B - 192.168.168.1/24, AP1 192.168.168.5, AP2 192.168.168.20

/ip dhcp-server network
add address=192.168.168.0/24 dns-server=192.168.168.1 domain=ammo.home gateway=192.168.168.1

/ip dns static
add address=10.10.10.15 name=unifi.ammo.home type=A

NOTE: The assumption is that the unifi APs are looking for two ways to connect to the unif controller.
a via DHCP option 43 contents. In this case there is no option 43 indicated ( this solution was provided by Method 2 on a previous post)
b. each device on the subnet will ask for DHCP configuration and will get, the IP address and mask, the gateway, the DNS server and the name of the "local" domain.
The AP is expecting to see a local domain. Then the AP asks DNS to return an address specifically for unifi.domain.name and in this case will then receive 10.10.10.15

c. Now lets ensure that path via WG from router to router exists as the APs will be searching for the UNIFI destination IP.

Hence in R2 allowed IPs, for peer of R1, we added 10.10.10.0/24

Hence in R2 we add a route
/ip route
add dst=10.10.10/24 gwy=WG-Client table=main

Hence in R2 we add firewall rule.......
add chain=forward action=accept in-interface=LANB out-interface=WG-Client src-address-list=UBI-APs

Now when the APs attempt to reach the destination of the unif controller, the routing there will be found by the router to be the wg tunnel, firewall rules will allow it, and the wireguard rules will match the traffic to the peer of R1 and send it on its way.

At R1 we need to ensure allowed IPs for peer router2 include 192.168.168.0/24
and thus will be filtered/accepted and allowed to exit the tunnel upon arrival at R1

At R1 we need corresponding firewall rule
add action=accept chain=forward in-interface=WG-Server dst-address=LANA src-address=External_APs
and thus the traffic will allowed to go to the unif controller

Finally at R1 we need to ensure a router back into the tunnel for said traffic.
add dst=address=192.168.168.0/24 gwy=WG-Server table=main

Another option:
-Does the OpenVPN in ROSv7 supports "bridge-mode" ?
If yes, then you can use to solve the problem ( the remote client directly bridged to the LAN network - pure L2 connectivity just like "bridge-to-lan" in WIFI ).
If no, then you need a small PC that running OpenVPN in bridge-mode ( example: INTEL NUC ).
MTU adjusting is needed ( example: MTU 1400 )

Does the OpenVPN in ROSv7 supports "bridge-mode" ?

Yes it does. OpenVPN does TUN and TAP (for MT this is IP mode and ethernet mode)
See video reference in this link (english subtitles, interesting demo) : viewtopic.php?t=194603#p990585


So OpenVPN it is yet another method to have L2 connectivity : after EoIP, MPLS/VPLS, PPTP/SSTP/L2TP with BCP, VXLAN, Zerotier
viewtopic.php?t=194310&hilit=BCP#p989135
Just as Zerotier , PPTP/SSTP/L2TP with BCP, OpenVPN is the L3 connection and the L2 LAN bridging , all in one

my calculation in like that
please add if u have something better

WAN's MTU - 1480 (pppoe)
Wireguard tunnel's MTU 1500
VXLAN's MTU - 1480

MTU clueless here so cannot help............ but here is the link to the user article based on this thread....... viewtopic.php?t=194646
Comments welcome.

1. UNIFI Controller to UNIFI APs - via Wireguard and EOIP. - viewtopic.php?p=990837#p990836
2. UNIFI Controller to UNIF APs - via Wireguard and VXLAN - viewtopic.php?p=990834#p990837
3. UNIF Controller to UNIFI APs - via Wireguard and DHCP Option - viewtopic.php?p=990834#p990838
4. UNIFI Controller to UNIF APs - via Wireguard and DNS+DHCP - viewtopic.php?p=990834#p990839
5. mDSN Discovery Between Home and Office Devices - viewtopic.php?p=990834#p990840
6. Identical Subnets Using WG Between Two Locations - viewtopic.php?p=990834#p990947

my calculation in like that
please add if u have something better

WAN's MTU - 1480 (pppoe)
Wireguard tunnel's MTU 1500
VXLAN's MTU - 1480

I wish I could say definitively. There is a docs on MTU, https://help.mikrotik.com/docs/display/ ... n+RouterOS but no examples for WG nor VXLAN.

You can always find MTU by using /tool/ping to www.mikrotik.com with the "don't fragment" option checked in "Advanced" and packet size of 1501, then keep reducing the packet size until the "packet too big" response comes back, that's MTU.

Working this out,
PPPoE (-8 bytes) = 1480 be fine - BUT could be higher 1492 or 1500 - depending if the upstream router support "baby jumbo" frames (e.g. modem may have allow 1514+ sized frames...)
Wireguard (-40 bytes) = 1440 (assuming IPv4 and worst-case for PPPoE)
VXLAN (-50 bytes) = 1380

The issue is the VXLAN at 1380 is going to cause a bridge to use that as the MTU everywhere. So perhaps setting VXLAN to 1500, and let WG, etc deal with fragmenting the packets may work better since the bridge be transparent. While the VXLAN don't suggest this, and while creating fragmentation seems wrong, the EoIP docs suggest doing this

MTU should be set to 1500 to eliminate packet fragmentation inside the tunnel (that allows transparent bridging of Ethernet-like networks so that it would be possible to transport full-sized Ethernet frame over the tunnel).

Also, the other end of the WG would need to match MTU (even if a higher MTU is available on it's WAN = lower MTU has to be set everywhere).

If someone want to correct me, feel free - I'm never 100% on the MTU calculation on the Mikrotik. The docs are little vague on some of this. And the "ping" is really what tells you actually going.

Had to bump this old thread.

Thanks to everyone who contributed time and expertise, your detailed and precise posts opened my eyes to a lot of information I didn’t even have before (the unknown unknowns if you will) and I assimilated all the new information you offered into work I have done subsequently, so again, thank you all.

In conclusion & lessons learnt (for the next guy) :

I managed to achieve what I wanted : VM of Unifi Controller running in Site A is seen as “on subnet” in Holiday Home Site B, all functionality works.

It was however entirely not necessary : By manually setting the inform-url parameter on Unifi devices you can effectively make all Unifi hardware talk to a Controller on any other network as long as you have underlying connectivity.

So no need to overthink a WireGuard Config that isn’t required, keep it simple, basic WG, check comms Site-A to Site-B, set inform-url parameter in devices, adopt, update, configure, enjoy.

Nice, being MT oriented, no clue on what unifi provides!!