YazFi Yazfi. cannot connect to devices on lan via public ip when on yazfi guest wifi

[coppo23]

AC86 and yazfi latest, If I am on the guest network wifi I cannot connect to my public ip iot devices via WAN whereas if I connect via mobile data I can.
If I open up yazfi guest to 2 way connection it will work but that rather defeats the object of a guest network.

It has cropped up/been noticed now because I wanted to allow a guest using our spare room to access the heating for the room.

I thought this did work going back a while so maybe something has changed recently. Cannot confirm

EG my public address is rpi.mydomain.orgortnumber. This will work fine if on mobile data but not if logged in on yazfi guest. Normal internet access is fine on yazfi guest.
If I am on wifi but not the guest network it will also work correctly.

I get the same problem with any iot thing including cameras so it is something about the ac86merlin and yazfi setup. Both are fully up to date.
Can anyone suggest something to look for please?

Many thanks
Andy

 

[eibgrad]

Sounds to me like you're referring to NAT loopback here, which is the ability to reference the public IP of port forwarded services while the client is actually inside that same LAN. IIRC, NAT loopback is limited to the private network (e.g., 192.168.1.0/24), at least by default. But you could probably add support for any of the additional IP networks of YazFi via a firewall script. I just don't know if that's sufficient, since I'm not aware of the finer inner workings of that script and what other measures it might be using to control/limit access. For all I know, the script might even already have the necessary rules for NAT loopback installed, and it's some other issue.

Might help to see a dump of the firewall to see it's that the case or NOT, or if something else is blocking it.

iptables -t nat -vnL
iptables -vnL FORWARD

 

[coppo23]

Thanks
I have puttied in and dumped the tables to a file but don't know enough to delve and understand. What am I looking for? (Didn't want to publish the whole file as it shows public ports and what they go to.)

 

[eibgrad]

Well that's certainly going to make things more difficult. As long as you hide your public IP in the dumps, it's of no use to anyone else.

Anyway, the more I think about, the fact you said it worked if you opened access between the two IP networks, NAT loopback is probably a none issue, since you're crossing network boundaries anyway. It's more likely simply the default rules YazFi adds to the ethernet firewall.

admin@lab-merlin1:/tmp/home/root# ebtables -t broute -L
Bridge table: broute

Bridge chain: BROUTING, entries: 3, policy: ACCEPT
-p ARP -i wl0.1 -j DROP
-p IPv6 -i wl0.1 -j DROP
-p IPv4 -i wl0.1 -j DROP

It's those rules that are denying ALL access from guest #1 on 2.4GHz (what I used for testing) to the private network. It's all inclusive. You'd need an exception for the guest network to access that one particular destination IP on the private network. But I'm not sure if it would work using the firewall-start script, which is only for the purposes of the IP firewall. IOW, there is no formal method in Merlin for adding user-defined ethernet firewall rules, at least a far as I know. You could try, but I can't guarantee it.

P.S. Here's the rule I think you'd need.

ebtables -t broute -I BROUTING -p ipv4 -i wl0.1 --ip-dst 192.168.1.100 -j ACCEPT

Of course the network interface and 192.168.1.100 in this case are just examples. You need to adjust the rule to your particular guest network and intended target.

 

[coppo23]

Cheers.
I have edited the dump and included it below. In the meantime I'll try and get my head around your last reply above

 

[coppo23]

Also ebtables output:
Bridge chain: BROUTING, entries: 12, policy: ACCEPT
-p ARP -i wl1.1 -j DROP
-p IPv6 -i wl1.1 -j DROP
-p IPv4 -i wl1.1 -j DROP
-p ARP -i wl0.1 -j DROP
-p IPv6 -i wl0.1 -j DROP
-p IPv4 -i wl0.1 -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.101.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.102.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto tcp -j DROP
admin@RT-AC86U-1EA8:/tmp/home/root#

 

[eibgrad]

To clarify, NAT loopback is only about the need to route out and in to the *same* IP network, typically when referencing the public IP on the WAN of a port forward. But after thinking about it a little more, I realized this is NOT what you're after. This access you need is NOT within the same IP network, but across *different* IP networks, so it's the ethernet firewall preventing access.

 

[eibgrad]

Also ebtables output:
Bridge chain: BROUTING, entries: 12, policy: ACCEPT
-p ARP -i wl1.1 -j DROP
-p IPv6 -i wl1.1 -j DROP
-p IPv4 -i wl1.1 -j DROP
-p ARP -i wl0.1 -j DROP
-p IPv6 -i wl0.1 -j DROP
-p IPv4 -i wl0.1 -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.101.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.102.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto tcp -j DROP
admin@RT-AC86U-1EA8:/tmp/home/root#

As I suspected. Basically all access to other local networks is denied, except for ping (icmp). If you enable one-way or two-way access w/ YazFi, you'll see that dump changes, and that certain types of access are now allowed. But as YazFi currently works, it's an all or nothing situation. You don't have fine control over individual devices to allow *some* access. Not unless you're able to modify it w/ your own rules.

P.S. Given it's also blocking ARP, you'd probably have delete that rule as well.

 

[coppo23]

Not sure I understand. I can be anywhere on my wifi/lan/mobile data and get through to the iot stuff. The only source location I cannot get through from is on either of the yazfi guest networks. My 'real' wifi lan subnet is 192.168.1.0 and the yazfis are on 192.168.5.0 and 192.168.2.0 respectively. That does soudn like NAT loopback not working as far as I understand it.

 

[eibgrad]

Not sure I understand. I can be anywhere on my wifi/lan/mobile data and get through to the iot stuff. The only source location I cannot get through from is on either of the yazfi guest networks. My 'real' wifi lan subnet is 192.168.1.0 and the yazfis are on 192.168.5.0 and 192.168.2.0 respectively. That does soudn like NAT loopback not working as far as I understand it.

Correct. That's why I said. I *now* don't think it's a NAT loopback issue. I think it's simply the ethernet firewall, which is managed by ebtables (see my posts above).

 

[coppo23]

Sorry - previous messages crossed I think.

I've no idea what the subnet 192.168.101.0 and 102.0 are!

 

[eibgrad]

BTW, whenever you're dealing w/ third-party scripting, these are the sorts of problems that are difficult for others to solve, esp. since we don't typically delve all that deeply into the inner workings of third-party authors. They are providing the feature and so ultimately they have to deal w/ any issues or limitations of their scripts. I'm just looking at this logically, from the outside in, to see what is likely the problem, and likely to solve it, short of the script's author making a change to accommodate more fine granular access across network boundaries.

 

[eibgrad]

Sorry - previous messages crossed I think.

I've no idea what the subnet 192.168.101.0 and 102.0 are!

I understand. Things can quickly get complicated. Those are special IP networks that ASUS added for the benefit of AiMesh, and only appear when using guest #1. In general, we recommend you NOT use guest #1 for that reason. It can sometimes cause problems because of these changes made by ASUS. Not that it should be an issue for this particular problem (at least I don't see it being a problem). The author of the YazFi script is aware of the potential presence of the 192.168.101.x and 192.168.102.x networks and has added rules to prevent access to them, just in case.

In short, for the purposes of your specific problem, just ignore those particular rules. They are NOT relevant.

 

[coppo23]

BTW, whenever you're dealing w/ third-party scripting, these are the sorts of problems that are difficult for others to solve, esp. since we don't typically delve all that deeply into the inner workings of third-party authors. They are providing the feature and so ultimately they have to deal w/ any issues or limitations of their scripts. I'm just looking at this logically, from the outside in, to see what is likely the problem, and likely to solve it, short of the script's author making a change to accommodate more fine granular access across network boundaries.

I understand. Things can quickly get complicated. Those are special IP networks that ASUS added for the benefit of AiMesh, and only appear when using guest #1. In general, we recommend you NOT use guest #1 for that reason. It can sometimes cause problems because of these changes made by ASUS. Not that it should be an issue for this particular problem (at least I don't see it being a problem). The author of the YazFi script is aware of the potential presence of the 192.168.101.x and 192.168.102.x networks and has added rules to prevent access to them, just in case.

In short, for the purposes of your specific problem, just ignore those particular rules. They are NOT relevant.

i'm (well) out of my depth I think.
I added ebtables -t broute -I BROUTING -p ipv4 -i wl0.1 --ip-dst 192.168.1.170 -j ACCEPT
As the 170 is my PI and wl0.1 is the first yazfi guest wifi (AFAIK). It didn't make any difference and when I rebooted - the new rule had gone.

It gets more confusing. As a trial with a sort of fresh start I moved away from guest1 to guest 2 on yazfi 2.4Ghz and am now getting all kinds of weird things from yazfi.
DHCP not working as expected, network suddenly disappearing and reappearing.


Worked around and it seems SOLVED - sort of. I attempted to change back to guest1 for both wifi bands.
It seems yazfi simply is not working even though it seems it is configured as expected.
The guest networks now dole out ip addresses on the 102.0 and 101.0 subnets and both guest networks operate as expected.
Guests have full access to internet but no local kit. They also now have access via public ip to the stuff I have let through on port forwarding as you would expect.

Thanks.
Andy

 

[Jack Yaz]

i'm (well) out of my depth I think.
I added ebtables -t broute -I BROUTING -p ipv4 -i wl0.1 --ip-dst 192.168.1.170 -j ACCEPT
As the 170 is my PI and wl0.1 is the first yazfi guest wifi (AFAIK). It didn't make any difference and when I rebooted - the new rule had gone.

It gets more confusing. As a trial with a sort of fresh start I moved away from guest1 to guest 2 on yazfi 2.4Ghz and am now getting all kinds of weird things from yazfi.
DHCP not working as expected, network suddenly disappearing and reappearing.


Worked around and it seems SOLVED - sort of. I attempted to change back to guest1 for both wifi bands.
It seems yazfi simply is not working even though it seems it is configured as expected.
The guest networks now dole out ip addresses on the 102.0 and 101.0 subnets and both guest networks operate as expected.
Guests have full access to internet but no local kit. They also now have access via public ip to the stuff I have let through on port forwarding as you would expect.

Thanks.
Andy

ebtables is the wrong place. i added a user script feature for this sort of requirement: https://github.com/jackyaz/YazFi#custom-firewall-rules

YazFi does some masquerading for "same network" NAT loopback, e.g.

-A POSTROUTING -s 10.14.20.0/24 -d 10.14.20.0/24 -o wl0.2 -m comment --comment "YazFi 2.4GHz 2" -j MASQUERADE

interestingly i don't see those rules in your output - unless you removed them?

 

[Jack Yaz]

But as YazFi currently works, it's an all or nothing situation. You don't have fine control over individual devices to allow *some* access. Not unless you're able to modify it w/ your own rules.

GitHub - jackyaz/YazFi: Feature expansion of guest WiFi networks on AsusWRT-Merlin, including SSID -> VPN, separate subnets per guest network, pinhole access to LAN resources (e.g. DNS) and more!

Feature expansion of guest WiFi networks on AsusWRT-Merlin, including SSID -> VPN, separate subnets per guest network, pinhole access to LAN resources (e.g. DNS) and more! - jackyaz/YazFi

github.com

rather than try and write something to meet every edge case, i added a feature where YazFi will run a script after it's finished, so you can tweak the rules, extend them, or whatever you like

 

[coppo23]

ebtables is the wrong place. i added a user script feature for this sort of requirement: https://github.com/jackyaz/YazFi#custom-firewall-rules

YazFi does some masquerading for "same network" NAT loopback, e.g.

-A POSTROUTING -s 10.14.20.0/24 -d 10.14.20.0/24 -o wl0.2 -m comment --comment "YazFi 2.4GHz 2" -j MASQUERADE

interestingly i don't see those rules in your output - unless you removed them?

I didn't remove rules - at least not intentionally! Yazfi operation seemed to get really upset when i disabled guest1 and enabled guest2 on yazfi.
When I then went back to guest1 only - yaz no longer worked, did not offer correct DHCP settings. However the network ssid and pw as set in yaz are working.

My set of rules now makes sense to me but it has reverted (I think) to the original merlin guest settings (see below) and Yazfi doesn't seem to be taking an active part even though it appears configured.
As it stands everything seems to be working and as a lot of our lighting and all the heating relies on it I'm not risking fiddling again today!
I do wonder why yazfi is doing nothing though.

Current ebtables chain output:

Bridge chain: BROUTING, entries: 10, policy: ACCEPT
-p IPv4 -i wl0.1 --ip-dst 192.168.101.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.102.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
admin@RT-AC86U-1EA8:/tmp/home/root#

 

[Jack Yaz]

easiest thing to do is use option 1 at the CLI and see if any errors pop out

 

[coppo23]

Just tried that wl0.2 failed validation.
According to ifconfig wl0.2 isn't in the list of links.
The config in yazfi gui for wl0.2 (if it is what I think - guest1 5ghz) looks fine.
Everything wifi/ IOt and guest related is working as expected even though yazfi appears not to be starting.

I had a purpose that yazfi was needed for some time back but things are simpler now and the network is fine for its current purposes.
Because this is a bit mission critical I'm going to leave it as is with crossed fingers until I have to make a change for another reason.

Again - many thanks
Andy

 

[bennor]

The config in yazfi gui for wl0.2 (if it is what I think - guest1 5ghz) looks fine.

Look at the YazFi config (option #3) via the YazFi command line interface if you haven't done so already. Sometimes one will spot issues there rather than the YazFi router GUI page.

Also double check that each YazFi guest client network has it's own separate IP address range even when a Yazfi guest client is not used (disabled).