@Jack Yaz may have a better cleaner way to do this (with or with out YazFi), but the following worked in some quick and dirty testing when using YazFi (with One Way and Two Way to guest set to No in YazFi) to allow traffic from either all Guest 1 clients to a specific IP address on the LAN, or from a single IP address on Guest 1 to a specific IP address on the LAN. The following
assumes one has knowledge of how to use SSH, has SSH enabled on their Asus-Merlin router, has YazFi installed and properly configured, knows how to use "nano", "vi" or SSH GUI programs
WinSCP to create a file, paste in code, edit that code to match their specific network settings. One may also want to create static/reserved IP addresses for their IoT devices to avoid certain issues. The YazFi GitHub Wiki page has additional general information on how to setup static/reserved Guest IP addresses for YazFi Clients.
https://github.com/jackyaz/YazFi/wi...e-and-ARP-records#a-note-on-dhcp-reservations
Create a custom script file as explained in the YazFi Custom Script section and set its execute permissions as indicated in that section.
https://github.com/jackyaz/YazFi#custom-firewall-rules
Remember to save any changes to the created file, then trigger YazFi to apply the changes either in the YazFi CLI (option #1) or by selecting the Apply button on the YazFi GUI page in Asus-Merlin's Guest section. Failure to do so won't apply the YazFi custom script file updates.
All Guests 1 IP addresses to single LAN IP address
For allowing all Guest 1 (wl0.1) clients to access a single IP address on the LAN try the following. Paste in the following code block into the custom script file one created and save that file then trigger YazFi to apply the saved file. Make the adjustment to the source (-s) IP address and destination (-d) IP address to match the IP address of the LAN device in each iptables line.
Code:
#!/bin/sh
iptables -I YazFiFORWARD -i wl0.1 -o br0 -d 192.168.1.100 -j ACCEPT
iptables -I YazFiFORWARD -i br0 -o wl0.1 -s 192.168.1.100 -j ACCEPT
Single Guest 1 IP address to single LAN IP address
For allowing a single Guest 1 (wl0.1) IP address to access a single IP address on the LAN try the following. Paste in the following code block into the custom script file one created and save that file. Make the adjustment to the source (-s) IP address and destination (-d) IP address to match the IP address of the Guest #1 device and LAN device in each iptables line.
Code:
#!/bin/sh
iptables -I YazFiFORWARD -i wl0.1 -o br0 -s 192.168.3.50 -d 192.168.1.100 -j ACCEPT
iptables -I YazFiFORWARD -i br0 -o wl0.1 -s 192.168.1.100 -d 192.168.3.50 -j ACCEPT
In the above example the NAS on the LAN has an IP address of: 192.168.1.100 and the single Guest #1 IP address of: 192.168.3.50.
What is generally happening is the following. In the first example; one is telling iptables to pass traffic to/from the Guest #1 (wl0.1) to the specific IP address on main LAN (br0). In the second example; one telling iptables to pass traffic to/from the specified IP addresses on the Guest 1 (wl0.1) to the specific IP address on the main LAN.
General Guest Network values:
2.4GhZ Network 1, 2, 3:
wl0.1
wl0.2
wl0.3
5Ghz Network 1, 2, 3:
wl1.1
wl1.2
wl1.3
5Ghz - 2 Networks (2 Ghz radios e.g. RT-AC53000)
wl2.1
wl2.2
wl2.3
There are likely better ways to script what you seek, but the above will get you started if using YazFi. One can likely modify the script to include additional Guest 1 (wl0.1) clients or to use different Guest networks (ex: wl0.2 or wl1.1) or to limit the traffic to just the Samba/SMB or FTP ports/traffic. In quick and dirty testing this worked for accessing a Synology NAS on the main LAN using a Windows PC connected to Guest 1.
Note: Due to the devices being located on different IP subnets certain features like network discovery may not work properly. One may have to manually enter the NAS IP address (ex: \\192.168.1.100) when trying to access the NAS from the Guest 1 client.
Final note: You proceed at your own risk!!! The above requires one to have some knowledge and skill. Improperly modifying iptables may yield unexpected results including potentially opening up security vulnerabilities or pinholes that could allow malicious actors/hackers to access your local devices/network. What works for me in my quick and dirty testing may not work for others for various reasons.