YazFi YazFi v4.x - continued

[Ripshod]

Has this developer version overwritten the old 4.4.5, or has the fix been added to the old 4.4.5? I've been running the 4.4.5 for ages, so long now I can't remember why

 

[bennor]

Has this developer version overwritten the old 4.4.5, or has the fix been added to the old 4.4.5? I've been running the 4.4.5 for ages, so long now I can't remember why

I assume you would need to reinstall (i.e. pulled down an updated version of) the 4.4.5 developer version to get the scroll bar fix for the 386.14 firmware since the pull request with the fix was initiated by Martinski a few days ago.

 

[bennor]

Using the great advice given here, I've created multiple IPtable exceptions that I've put into the myscripts.sh file.

What is the proper syntax to add my own comment line within the file, just so I can keep track of what each exception is for?

#? Or ##?

I found this tutorial, but this seems very different from what I need:

https://www.cyberciti.biz/faq/how-to-add-comments-to-iptables-rules-on-linux/

See the following link which has an example (information is from 2018 so take it for what it's worth):
https://github.com/RMerl/asuswrt-merlin.ng/wiki/Iptables-tips

Appears you can use a single # at the start of the comment line/text in the custom script.

 

[fotingo]

I updated to 4.4.5 and it made things worse for me. Devices that used to be accessible via LAN only while internet was disabled became inaccessible. I had to go back to 4.4.4 and issue went away right away.

 

[bennor]

Devices that used to be accessible via LAN only while internet was disabled became inaccessible.

It may help if you post your YazFi configuration. Can you provide more detail about what "accessible via LAN only while internet was disabled" means? Are you using any custom firewall scripting? If so what is the script? Did you try rebooting the router after updating YazFi?

How did you update to the 4.4.5 develop? Did you update to 4.4.5 develop by running the following on the router via SSH or by some other method?

/jffs/scripts/YazFi develop
/jffs/scripts/YazFi forceupdate

 

[fotingo]

/jffs/scripts/YazFi develop

/jffs/scripts/YazFi forceupdate

That's is how I updated to 4.4.5.

For example, this is wifi network for my cameras. As you can see, internet is disabled, but I can still view them on their respective smartphone app LAN only.
But, if I update to 4.4.5, it breaks the connection and I am not able to view them anymore on the app..only one becomes available.

I don't use any firewall rules on YazFi.

 

[bennor]

But, if I update to 4.4.5, it breaks the connection and I am not able to view them anymore on the app..only one becomes available.

To confirm the router is not 192.168.2.1, correct?
What is at IP address 192.168.2.1? If something like Pi-Hole or similar, check it's settings to ensure it's properly configured and not blocking the YazFi clients.
Each YazFI IP address range has to be unique and not the same as the routers LAN IP address range.
Doesn't seem to make sense if all access to the YazFi connected cameras is blocked, but you can still access one camera but not others. Check the camera settings, if you can, to ensure they are receiving the correct IP address from YazFi.

 

[fotingo]

The router is 192.168.1.1. The cameras are receiving the IP range within the 192.168.2.x network, they just become inaccessible when using 4.4.5. As soon as I went back to 4.4.4, it fixes the issue right away.
I don't make any changes to the camera settings or any other settings.. I simply update and that's it, so it should work the same whether I'm on 4.4.4 or 4.4.5, but for some reason, it doesn't like 4.4.5. Something is blocking some of the connections... but anyway, since I don't have any issue with the 4.4.4, I will stay on that version.

The only issue I've always had is with the IoTs. The IoT devices do not work at all unless I enable Internet access to them, but it was determined that the issue was with these types of IoTs requiring internet access in order for them to function.

I only tried updating to v4.4.5 to see if that would take care of the issue with the IoTs, but it didn't, but then I noticed the security cameras became inaccessible where that was never an issue for me....so I went back to 4.4.4 and all is well... except the IoTs, but I will have to learn to live with that for now.

And yes, I've tried in the past the YazFi firewall from Github to see if that enabled access to the IoTs, but it never worked for me.
The IoTs on are on a different network, 192.168.3.1.

 

[lokester]

Currently running Asus AC3100 w/Merlin 386.14_2. I have "many" ESP based IOT devices connecting to a Guest network that DOES HAVE access to Intranet allowed so they can push data and receive commands via local MQTT Broker on Raspberry Pi connected via ethernet. All devices on my router are on same LAN IP range (172.16.85.2 thru .254) and I manually assign IP addresses to these devices via /jffs/configs/dnsmasq.conf.add Everything works fine but just installed YazFi thinking I can better isolate my IOT device exposure (have not enabled it yet). Reading up, does the proposed configuration look correct:
a. On main LAN settings, do I need to change my Subnet Mask to 255.255.0.0 ?
b. On YazFi Guest 1, enable it and set IP to 172.16.90.0
c. DHCP Start 2 and End 254
d. DNS Server 1 and 2 to 172.16.90.1
e. Force DNS ? (I really don't know what this means)
f. Allow Intranet Access - NO
g. Redirect to VPN - NO
h. One way to Guest - YES
i. Two way - NO
j. Client Isolation - NO

Then to allow communication from IOT devices to local MQTT broker:
An example script to allow a guest on 2.4GHz guest 1 to talk to a specific IP address on the LAN:

#!/bin/sh
iptables -I YazFiFORWARD -i wl0.1 -o br0 -d 192.168.1.50 -j ACCEPT (but change 192.168.1.50 to the IP of my Raspberry Pi/MQTT device)

Last question - In my dnsmasq.conf.add file, can I list both the 172.16.85.x devices as well as my IOT devices 172.16.90.x or do I need to do something different?

 

[iTyPsIDg]

It sounds like you want two subnets (172.16.85.X and 172.16.90.X). If that is correct, then you would need to use a /24 subnet mask (255.255.255.0). A /16 subnet means everything in 172.16.X.X can communicate with everything else as it is on the same network.

If you click where it says Force DNS, it gives an explanation:

If you force, you can't add a second DNS. Given you were intending to put the same IP for 1 and 2, forcing makes sense for you instead (except if you have a VPN with redirect for the guest network and it is set to Exclusive on the VPN page).