Make IoT devices on one-way-to-guest YazFi VLANs discoverable on main LAN

[treefrog]

(New to Asuswrt, Merlin, and router hacking in general, so struggling to get up to speed with all the tools here... could use some extra help please)

My goal is to have a reasonably secure VLAN for my IoT devices, but still be able to interact with them through devices like my phone connected on the main LAN.

I setup YazFi to create a VLAN for my IoT devices. I want One-Way-to-Guest for this VLAN because the whole point is to isolate sketchy devices on my network. With One-Way, the devices aren't discoverable in my phone apps (my phone is on the main LAN) -- the control apps think the devices are offline. I can ping the devices from the main LAN, so it does seem like One-Way lets me connect to them, as promised. I can make them discoverable like normal with Two-Way, but Two-Way breaks the isolation so why even have a VLAN at that point.

So I think I'm trying to figure out how to setup the YazFi guest VLAN to be One-Way-ish -- the sketchy IoT devices can't initiate a connection out of the VLAN, but they can still broadcast their presence so my phone apps know they exist and can send commands into them.

I understand this gets deep into "well, every devices is different so different protocols, ymmv, etc etc". And yes, but it seems like Bonjour and Matter devices rely on mDNS, and from what I've been able to gather, getting mDNS to work will make a bunch of devices work, so lets limit ourselves to that lowest common denominator. It's also the only thread I've got -- I don't know how "discoverability" is implemented in this world, so if I should be looking at something else, someone please let me know

Still new to mDNS, but sounds like main limitation is it doesn't go across subnets. However, Merlin ships with something called Avahi that rebroadcasts mDNS if you set a enable-reflector=yes configuration property. It seems that YazFi adds a /jffs/scripts/avahi-daemon.postconf file with contents including:

echo "[reflector]" >> "$1" # YazFi
echo "enable-reflector=yes" >> "$1" # YazFi

Since my IoT devices are discoverable when I set the YazFi Two-Way-to-Guest option, it seems like YazFi is enabling this setting on some configurations (ie Two-Way-to-Guest), but not on One-Way-to-Guest networks.

So, I thiiiiink in order to make my devices discoverable, I need to turn on Avahi's reflector for my IoT VLAN even though YazFi turns it off with the One-Way configuration? Does anyone know what the best way of doing this is, or if my story of how YazFi interacts with Avahi is even correct? Or do I need to create some firewall rules to get my goal? Or is one-way-but-with-discoverability simply a hopeless goal?

Stack:
- RT-AX88U Pro as Wireless Router
- Merlin 3004.388.4
- YazFi 4.4.4

 

[Gary_Dexter]

What devices?

 

[bennor]

Yes, what IoT devices you are trying to use would be helpful. Why cannot the phone access the IoT devices through the internet rather than having to enable one way to guest in YazFi?

You may want to look into the YazFi custom firewall rule scripts if you need to allow specific traffic from or two specific YazFi clients or main LAN clients.
https://github.com/jackyaz/YazFi#custom-firewall-rules
https://www.snbforums.com/threads/allowing-access-to-selected-network-devices.80405/#post-784521
Some recent discussions on custom firewall rule scripting:
https://www.snbforums.com/threads/allow-client-in-isolated-network-to-speak-to-main-network.87862/
https://www.snbforums.com/threads/help-with-iptables-script.87827/

 

[treefrog]

Yeah, I think this is down in "every devices is different so figure out the protocol" land.

I had a different IoT device on the IoT VLAN that does show up and is controllable on my (main LAN'd) phone's app, so I think my comments about YazFi disabling mDNS reflection was just wrong. It does seem the mDNS reflector does work across one-way-to-guest VLANs, so my problem is now figuring out how to work with my specific device's protocol.

So my specific device is the new TP-Link Matter switches -- problem is getting them to show up in Kasa app. Googling "Matter" and "VLAN" gets a whole lot of other frustrations or HA bridge instances hooked up to both VLAN interfaces (which I'm not interested in... yet...) but maybe we can figure out the simple phone app case.

The other linked threads seem to be mostly talking about having a specific device communicate in/out of the VLAN. I'm more interested in "any" device being discoverable than specific devices talking to specific servers, so I think this is getting into network details on multicasting, which I'm not very familiar with...

I've seen some references that say Matter devices use port 5540 for multicasts. mDNS is defined as port 5353, so I assume this means the Avahi mDNS reflector solution doesn't work for Matter devices. Where I'm lost is:
- people also say Matter is over IPv6, but these smart switch devices are all on IPv4 wifi... does the principle still stand on IPv4? Doesn't YazFi have some limitations on IPv6?
- if the solution is "use a reflector for port 5540", is that something Avahi can be configured to do?
- or if solution is creating a firewall forwarding rule for UDP 5540, that won't necessarily apply to multicast messages because they don't hop across subnets anyways, right?

 

[treefrog]

Update on going down the TP-Link protocol rabbit hole for the records... tl;dr: I think it's a dead end because TP-Link's discovery protocol can't be done with VLAN isolation. Here's why.

Googling around, people have reverse-engineered the TP-Link / Kasa discovery protocol. It seems to be the app sends out a UDP broadcast on port 9999 basically asking "Yo, who's alive in this house? Get me your sysinfo!" With default IP configs: on my main LAN this broadcast goes to 192.168.50.255, on one of the VLANs it goes to 192.168.3.255. The TP-Link devices then respond back to the sender of the broadcast with their info, and they show up live in the app.

First problem is UDP broadcasts by design don't go across subnets. So my phone in 192.168.50 broadcasts to .50.255, but the poor schmucks on 192.168.3 never hear it.

I figured out you can use iptables with TEE to get around this by re-broadcasting into the VLAN. However,

# iptables -A YazFiINPUT -t mangle -i eth0 -d 192.168.50.255 -j TEE --gateway 192.168.3.255
iptables: No chain/target/match by that name.

# modprobe xt_TEE
modprobe: module xt_TEE not found in modules.dep

Uh-oh. According to this recent thread https://www.snbforums.com/threads/i...match-and-tcpdump-problems.87785/#post-877579, TEE is not being compiled on current Merlin.

Figuring out how to compile TEE manually is a bit beyond what I want to do right now, but not sure if it would even work if I did... the other part of the TP-Link protocol is the devices respond back to the device that created the "who's in the house?" broadcast. But the TP-Link's are inside their one-way-to-guest subnets, so even though I could theoretically rig it so they hear the broadcast, I think they will be blocked from responding. UDP is stateless, I think, so I believe there's no way of telling the router "let this response go through" without punching a general 2-way UDP:9999 hole back into the LAN, which breaks the desired isolation.

So long story short, I think this is a dead-end if I want to maintain my pure isolation because TP-Link implemented their discovery protocol as a UDP "hey, who is alive?" question-from-controller instead of a mDNS-style "hey, if anyone's listening, I'm a smart switch that's alive" broadcast from the device.

 

[fotingo]

Same issue here. With my TP-Link IoT devices, they will not work in YazFi unless I enable Internet Access to them which kinda defeats the purpose of isolating them.

Before I ran into YazFi, I had these IoT devices connected to the main wifi Network, then blocking Internet Access via Parental Controls/Scheduling. They worked fine and I was able to always control them in the app even though they had no internet access.

But, I always wanted to get those IoTs on a different Network and still keep them off the internet as well. I guess these type of IoTs will not work if you segregate them from the LAN unless you give them Internet Access as well.

It's strange because my wireless cameras which are also TP-Link work fine segreged and wihtout Internet access.