Network discovery over wireguard

I’d consider myself a newbie but I should give myself some credit for how far I’ve come…so I will try to be as detailed as possible however if I’m being an idiot, I can take constructive criticism.

At work, I have a CCR2004-16G-2S+ as our router. We have a static IP and routed /27 CIDR block of IPs (probably not relevant but may be helpful), served by Cox cable (but fiber coming in next month).

I setup 3 subnets. 192.168.2.0/24 for general devices/computers, 192.168.3.0/24 for security cameras and 192.168.4.0/24 for VOIP phones. This is working quite well!

I’m using two identical CRS354-48P-4S+2Q+ switches, one handles the general device/computers network and is essentially in its default configuration less a couple small tweaks. The second CRS has two bridges, and is split in half with the VOIP phones on ports 1-24 and the security cameras on port 25-48. Easy enough so far.

At home, I have a hAP AC3 (which by the way is AWESOME) that gets its WAN connection via Starlink (not so awesome but one of few options). I have the Starlink in bridge mode with the RJ45 adapter, The hAP is successfully operating as a router, passing traffic, firmware updated, all the good stuff. The LAN address range at home is 192.168.33.0/24

I have wireguard setup between work and home, and I have set a route, DST address=192.168.0.0/19 and gateway=wireguard1, and also added 192.168.0.0/19 to the allowed IP list at home. I can successfully access devices at work from my computer at home no problem.

While I, as the guy that setup the whole system have no problem referring to things by IP addresses that I have memorized, this is not the case for my partner that is used to accessing devices via network discovery (network tab in windows). He wants a better solution and I’m just thinking a bunch of desktop shortcuts, but I figured I’d ask a question here first -

Please help me understand, is the reason that none of the devices at either end of the wireguard tunnel show up via network discovery because network discovery only works for devices on the same subnet? I’m going to base the next paragraph on this assumption.

Again, learning here, and NAT is an area I struggle grasping. I was thinking, for the most important devices, could I set a NAT rule at home so that the devices on the other end of the tunnel appear as being on the same subnet to the computer at home? I have no idea if this is possible or how to go about it. I am assuming this is needed because wireguard documentation is explicit that you can’t have the same network address on both ends of the tunnel…but is there a better way?

Look forward to any feedback and chance to learn!

Dexter

Please help me understand, is the reason that none of the devices at either end of the wireguard tunnel show up via network discovery because network discovery only works for devices on the same subnet? I’m going to base the next paragraph on this assumption.

Depending in its implementation of this “discovery” very likely that is the root-cause.
And “Wireguard” is a routed solution, any broadcast/mDNS-multicast will not travel down to clients/peers as far as I understood since you have multiple IP-networks glued together.
Even further, mDNS would not even travel between your “camera” VLAN and other VLAN’s locally on the office (it does not travel outside a given network)

This whole NAT thing will not work for eg. mDNS (very often used for discovery)

I can’t imagine in this small setup you have that many devices, so I think some links/pointers/shortcuts on the PC of the partner is not a bad idea…

Or an EOIP layer over wireguard.
Even ROMON works then.

Yes, but EoIP tunneling is bridging right ? So this means the user must “extend” his office LAN down to the home. What about the different VLAN’s in the office.
Let’s say IPCAM VLAN in the office and IOT/MEDIA VLAN in the office, both containing mDNS shouting stuff that you want to see at home.
How do you reconcile that back at the home location where you have a PC with a certain IP in a certain network-space ?

Don’t know.
I only used that eoip tunnel once with a setup over wireguard in France. It worked for what I needed.
Nobody was shouting there :laughing:

I do agree with your previous statement though that it might be easier for such a small environment to setup dedicated links to the required ip addresses.

You can do it, I have Wireguard set up between my house and another house with mDNS and SSDP working between them too. The IP traffic flows between the subnets normally as routed traffic over the Wireguard link but uses EoIP over the link as well with bridge filtering.

EoIP with bridge filters are added here so only SSDP (good for things like UPNP/DLNA discovery for multimedia systems) and mDNS (many things including printer discover/Airprint, Airplay, Chromecast etc) get through and all other layer 2 traffic from each subnet is blocked - you don’t want DHCP leaking across to the other subnet.

You need to do this filtering on each end once you get EoIP working over the Wireguard link. You don’t need to turn on IPSEC for EoIP as it’d be redundant in this case. You’ll have to do some homework to figure out what filter options to add for other broadcast based discovery mechanisms.

/interface bridge filter
add action=accept chain=forward dst-address=224.0.0.251/32 dst-mac-address=\
    01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF dst-port=5353 ip-protocol=udp \
    mac-protocol=ip out-interface=EoIP src-port=5353 comment=mDNS
add action=accept chain=forward comment=SSDP dst-address=239.255.255.250/32 \
    dst-mac-address=01:00:5E:7F:FF:FA/FF:FF:FF:FF:FF:FF dst-port=1900 \
    ip-protocol=udp mac-protocol=ip out-interface=EoIP  
add action=drop chain=output out-interface=EoIP
add action=drop chain=forward out-interface=EoIP

Also see my original post which extends this bridge filtering idea to allow mDNS relaying between VLANs without a user space reflector program like Avahi.

http://forum.mikrotik.com/t/mdns-repeater-feature/148334/179

network discovery because network discovery only works for devices on the same subnet?

Network discovery is mostly based on broadcast/multicast. And those packets are not routed from one network to another over the router.
That the subnets are different, has to do with a routing requirement.
(If the destination is in the same subnet as the sender, the sender will not even use the gateway/router, but go directly to the destination, getting the MAC address via ARP)
So there is one poor-mans router option: using proxy-arp, so the router will react with it’s router MAC address on the ARP request for an IP address on the other end of the route.

Multicast/broadcast discoveries have their own solution, to pass over routers (L3 connections)
NBT: netbios over TCP, a MS Windows implementation. Used for SMB shared drives, Name registration via broadcast. With master browser elections via broadcasts. Needs a WINS server (Windows name server) for a routed network. The Netbios client must be set to use WINS, or is set as hybrid NBT.
mDNS: multicast DNS, for small networks. As multicasts are not routed, again a server is needed (mDNS reflector, AVAHI (https://www.avahi.org/), Bonjour server, or other mDNS reflector

Good thread! ZEROTIER is the clear answer both being arm devices.

@OP, to be clear the person requiring access to devices at work lives at home so its HOME TO WORK flow?

@ UpRunTech, were the subnets you connected via EOIP, different. My understanding is that spanning has to be to the same subnet??
or DISCOVERY needs to be in the same L2 segment. Therefore I dont think its normally possible…

I’ve done it with 2 different subnets in the past.

I dont believe its possible or more accurately I dont think its stable if you do… Even in the same subnet its very tricky to get right.

This does scream like a ZeroTier problem & actually solvable on RouterOS since all devices mentioned are ARM. Wireguard does not do multicast, which is what’s needed for most “discovery” protocols is what you’re up against here.

You can create a ZT network for the LAN you want remote access, wireguard would not be involved in this. Or you can add multiple ZT networks, one for each VLAN, if you want multiple broadcast scopes remotely. The ZT does support multicast, and while you have a static IP at one end, ZeroTier doesn’t actually require this – both side can be CGNAT or whatever. Since you can turn on/off the ZT networks to control what’s discoverable remotely is helpful since you may not always want to see those devices. And proxying discovery (or if you manage multiple sites/customer) can result in too many results sometimes (and complex no matter how you do it).

If it was mDNS, you be able to put the cameras/devices into a real DNS server/domain, which mDNS will use – but you’d need an external DNS server since Mikroitk DNS doesn’t support the DNS PTR records needed for DNS-SD. And most cameras likely use SSDP (part of the PnP specs) for discovery, not mDNS (or it’s unicast cousin DNS-SD, both part of the IETF RFC specs), so even converting mDNS into unicast DNS wouldn’t help if using SSDP. And, importantly no proxying would help with Wiregard alone – WG does not pass multicast packets whether from the LAN or proxied.

If the need is only between the CCR and another Mikrotik, using an EoIP (or theoretically VXLAN*) tunnel might work here too. But that’s more useful when you really do want the whole network bridge to another location. And the EoIP tunnel can use WG as it’s transport. It’s not hard to setup however, you just use the remote Wireguard address as the remote tunnel address, and put the EoIP in the right bridge/pvid on BOTH sides. Only side-effect is MTU is reduced. I get the need may also be from mobile/desktop devices too, thus ZeroTier approach seems better IMO since there are iPhone/etc clients.

You can also dig into the discovery methods of the devices you’re using, typically they have some scheme to do discovery outside of multicast. But this be an per-application/device exercise – so if only one thing digging into the device’s docs may help as they may have non-multicast discovery method. Thus EoIP or ZeroTier seem like reasonable approaches since it be device-agnostic.

\

  • I can’t say how multicast works over VXLAN – it has some different mechanisms for multicast IPs (which is what’s needed for discovery), based on the docs

Lots to take in here, and a lot more help than I thought I’d get so thank you all!

First, I want to clarify a requirement of what we are trying to accomplish before getting into the details - the flow is home to work - we only need the computers at home to see the devices at work, and not vice versa. I don’t need my receptionist connecting to my smart TV at home :laughing:

To be clear, I don’t need the cameras / voip mDNS, just the “computers” network because the cameras / VOIP only need to be directly accessed for setup and I can do that directly via their IP. The NVR sits on both the cameras and the computers network, so access to that is equal to the other devices on the computers network.

mDNS is the key I need to read up on, the gap in my knowledge. I read a brief summary, and the mechanism now makes a lot more sense, and I understand why NAT wouldn’t do anything for me.

I also think bpwl is onto something…the main devices my partner is trying to access through the wireguard tunnel are Windows computers, and printers…I am already running a windows Active Directory Domain Controller at work, and I have a server at home the data backs up to. I can make the server at home an additional domain controller, and enable its DNS capability, then it should be trivial from there.

I was looking into WINS Microsoft recommends avoiding and decomissioning WINS servers for DNS now:

If you do not already have WINS deployed on your network, do not deploy WINS - instead, deploy Domain Name System (DNS). DNS also provides computer name registration and resolution services, and includes many additional benefits over WINS, such as integration with Active Directory Domain Services.

If you have already deployed WINS on your network, it is recommended that you deploy DNS and then decommission WINS.

And that’s the a good approach. If you can get these discoverable things into unicast DNS that’s really the best plan. You options are limited with RouterOS since there DNS services are limited, but if you have Windows Active Directory, that is totally the place to do this. And work will with wireguard just fine.

If you want to read up on mDNS (and importantly it’s unicast variant DNS-SD)… This may be helpful:
http://www.dns-sd.org
(ignore the dated pictures – this all works EXACTLY the same on MacOS Ventura, or anything with Bonjour like Windows)

And the RFC on it pretty readable: https://www.rfc-editor.org/rfc/rfc6763

I was looking into WINS Microsoft recommends avoiding and decomissioning WINS servers for DNS now:

Yes WINS is old, very old, just as I am, and as is NBT (Netbios over TCP). It went with the TCP/UDP ports 137,138 and 139, and was replaced by connection on TCP 445 after Windows 2000.
It was just as exemple (NBT should have been disabled long ago). I had to manage multisite setups for 20 years with this. Today DLNA, SSDP, Upnp would be better exemples, of which I lack detailed knowledge however.

With the help of some friends, as I am not worthy or capable.
@HighTechLab This should solve your request!
https://forum.mikrotik.com/viewtopic.php?p=990840#p990840

As for subnets seeing each others broadcasts it depends on the protocol.

mDNS does most communication all with broadcasts. For example, A client blurts out “who has this kind of service?” and the service device replies with a broadcast “that’d be me”. As long as the broadcast can get to the other subnet the device at the other end it’s like a big shouting match and everyone can hear each other. If a client wants to use a service that’s being advertised it can find the service IP address explicitly written in the contents of the message . I can’t speak for all things that use mDNS work that way but Chromecast and Airprint and CUPs have worked for me both ways over the link.

SSDP uses broadcasts for initiating client queries to servers. The server replies with via unicast routed UDP. VLC, Windows and an LG TV can discover my media server using SSDP and DLNA this way. I think the replaying server infers the IP address from the source IP in the packet from the client before it send it’s private reply. MythTV proved to be a bit of a pain as it won’t respond to any unicast client SSDP UDP connection requests if they aren’t a member of any of the subnets MythTV see on it’s network interfaces. I had to do some cheeky srcnat/dstnat to get it working.

You can use the bridge filtering of MAC source addresses on the EoIP interface to filter out mDNS traffic from particular servers if you don’t want them accessed or known from the other side. If you watch the EoIP interface with torch there is a lot of mDNS traffic especially once you get IOS and MACOS devices on the network.

@UpRunTech can you share hot did you create EoIP tunnel over wireguard?
Simple scenatio, Smart TV on lan, mobile device (iphone) on wireguard, different subnet, can mobile device discover AirPlay service?

Many thanks to all who have contributed so far. I’ve got loads of reading to do and my work cut out for me, but this has been fun and got me on the right track to get a solution of some degree to make this work well.


I will say, my Mikrotik and networking experience so far has been along the lines of “If it’s difficult, then someone has made a tool/protocol for an easier way”. I’m hooked.

Hello, but then in the end you solved? if you could explain how?

Set up an EOIP tunnel using the 2 WG end point addresses.
Connect that EOIP tunnel on both ends to bridge.

Done.