WireGuard and placing a client on the LAN segment of my network

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 :slight_smile:

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. :slight_smile:

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:BCP_bridging_(PPP_tunnel_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.

vxlan.JPG

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. :slight_smile:

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.

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 :wink: 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…

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! :slight_smile:
How did I manage to glean that from the OP, probably his comment my HOME, and my vacation home, :wink:

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.

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-with-dhcp-option-43-on-pfsense-mikrotik-and-others.htm

sweet link…