YazFi YazFi - enhanced AsusWRT-Merlin Guest WiFi inc. SSID <-> VPN Client

[Jack Yaz]

Hey Jack Yaz, updated 86U to 1.3.7 with no issues, thank you!

Quick question: are these two commands supposed to be in the firewall-start script?

#!/bin/sh

/jffs/scripts/YazFi & # YazFi Guest Networks

./YazFi & # YazFi Guest Networks

1.3.8 has been pushed to hopefully resolve this.

 

[ldee]

Do you mean in the policy routing UI? If so please send a screenshot

No, I don't think so. I added the routes like that (https://fatmintech.files.wordpress.com/2014/11/static_routes_asus_rt-ac66u.jpeg). However, I put 255.255.255.255 as a netmask (because it's a single IP) and used my public IP as Gateway address. The public IP is statically configured on the router, so there shouldn't be any routing issues.
I guess, I should have added them somewhere else? Can you tell me where and how?

 

[Jack Yaz]

No, I don't think so. I added the routes like that (https://fatmintech.files.wordpress.com/2014/11/static_routes_asus_rt-ac66u.jpeg). However, I put 255.255.255.255 as a netmask (because it's a single IP) and used my public IP as Gateway address. The public IP is statically configured on the router, so there shouldn't be any routing issues.
I guess, I should have added them somewhere else? Can you tell me where and how?

I suspect VPN Policy Routing takes precedence. You'd need to check your router's RPDB to be sure.

ip rule show

ip route show

 

[JaimeZX]

OK! It was working famously but didn't seem to survive a reboot. What to do?

Edit:

Asus:/jffs/scripts# ls
YazFi             disk-check        firewall          init-start        pre-mount         services-stop
amtm              dnsmasq.postconf  firewall-start    post-mount        services-start    wan-start
Asus:/jffs/scripts# head firewall-start
#!/bin/sh
sh /jffs/scripts/firewall start skynetloc=/tmp/mnt/Sandisk4/skynet # Skynet Firewall Addition

[ -x /jffs/dnscrypt/manager ] && /jffs/dnscrypt/manager fw-rules

./YazFi & # YazFi Guest Networks

Edit: Reboot due to upgrade to 384.5. I ran ./YazFi manually, seems to have started up okay but I don't see it listed in htop?

 

[Jack Yaz]

OK! It was working famously but didn't seem to survive a reboot. What to do?

Can you check what's in firewall-start?

YazFi should install itself there automatically.

 

[JaimeZX]

Yep... guessing you typed this as I was copying firewall-start into my previous post.

So I *assumed* it wasn't there because when I reloaded the GUI I saw all the clients under Network Map with the main router subnet. Now, none of them are listed there, only the one hard-wired client.

If I look under System Log > Routing Table I see the YazFi subnets, but when I look in Wireless Log I only see clients with the router subnet, as well as on the DHCP Leases page. Which makes me think that the router is handing out DHCP leases before YazFi starts. ??

 

[Jack Yaz]

Yep... guessing you typed this as I was copying firewall-start into my previous post.

So I *assumed* it wasn't there because when I reloaded the GUI I saw all the clients under Network Map with the main router subnet. Now, none of them are listed there, only the one hard-wired client.

If I look under System Log > Routing Table I see the YazFi subnets, but when I look in Wireless Log I only see clients with the router subnet, as well as on the DHCP Leases page. Which makes me think that the router is handing out DHCP leases before YazFi starts. ??

YazFi writes to dnsmasq.conf.add so when dnsmasq starts for DHCP it will set up with the correct addresses. Can you send me a copy of /jffs/configs/dnsmasq.conf.add please?

Ah, firewall-start is using a relative path. Which version of YazFi are you using? I thought I'd resolved that issue with 1.3.8, so if you're running that version I have more work to do!

What's likely happened is firewall-start path is wrong, so while DHCP started with the correct addresses, the firewall rules didn't load to prevent clients from getting the "br0" set of rules.

 

[owine]

Can’t get this working but not sure if it’s a YazFi issue or a OpenVPN issue. My issue is that all of my traffic is being redirected through the VPN on my regular SSID rather than just the VPN SSID(s). I have internet redirection set to Policy Rules Strict. Likely a regular VPN configuration issue or something with YazFi?

 

[Jack Yaz]

Can’t get this working but not sure if it’s a YazFi issue or a OpenVPN issue. My issue is that all of my traffic is being redirected through the VPN on my regular SSID rather than just the VPN SSID(s). I have internet redirection set to Policy Rules Strict. Likely a regular VPN configuration issue or something with YazFi?

Can you send me a screenshot of your policy rules please?

 

[owine]

Can you send me a screenshot of your policy rules please?

Here they are for:

VPN4 (wl0.1)

VPN5 (wl0.2)

No errors when I run the script. Everything LOOKS like it's configured as I want it, but all of my traffic is getting caught in the VPN (VPN4 in this case) no matter the SSID. I'm on a AC3100 and 384.5 fwiw.

Thanks

 

[Jack Yaz]

What does

ip rule show

ip route show

return please? Feel free to blank out any public IP(s) you are concerned about posting

 

[owine]

What does

ip rule show

ip route show

return please? Feel free to blank out any public IP(s) you are concerned about posting

admin@RT-AC3100:/tmp/home/root# ip rule show
0:    from all lookup local
32766:    from all lookup main
32767:    from all lookup default
admin@RT-AC3100:/tmp/home/root# ip route show
*.*.*.* dev eth0  proto kernel  scope link
10.16.0.0/24 dev tun22  proto kernel  scope link  src 10.16.0.1
10.17.89.0/24 dev br0  proto kernel  scope link  src 10.17.89.1
10.17.110.0/24 dev wl0.2  proto kernel  scope link  src 10.17.110.1
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
10.17.100.0/24 dev wl0.1  proto kernel  scope link  src 10.17.100.1
*.*.*.*/22 dev eth0  proto kernel  scope link  src *.*.*.*
127.0.0.0/8 dev lo  scope link
default via *.*.*.* dev eth0

 

[Jack Yaz]

Well now that's peculiar. There's no policy routing occurring at all. Redirect internet traffic set to policy or strict for both clients? (which I need to add as a prompt in YazFi, come to think of it!

I don't think this is a YazFi issue, as I would expect "ip rule show" to refer to the ovpn tables.

 

[owine]

Well now that's peculiar. There's no policy routing occurring at all. Redirect internet traffic set to policy or strict for both clients? (which I need to add as a prompt in YazFi, come to think of it!

I don't think this is a YazFi issue, as I would expect "ip rule show" to refer to the ovpn tables.

Well I guess I should have run the commands with the VPNs up running, huh. Here's the new output:

admin@RT-AC3100:/tmp/home/root# ip rule show
0:    from all lookup local
10701:    from 10.17.100.0/24 lookup ovpnc4
10901:    from 10.17.110.0/24 lookup ovpnc5
32766:    from all lookup main
32767:    from all lookup default
admin@RT-AC3100:/tmp/home/root# ip route show
209.99.93.37 via *.*.*.* dev eth0
*.*.*.* dev eth0  proto kernel  scope link
209.99.21.37 via *.*.*.* dev eth0
10.16.0.0/24 dev tun22  proto kernel  scope link  src 10.16.0.1
10.17.89.0/24 dev br0  proto kernel  scope link  src 10.17.89.1
10.17.110.0/24 dev wl0.2  proto kernel  scope link  src 10.17.110.1
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
10.3.37.0/24 dev tun14  proto kernel  scope link  src 10.3.37.42
10.3.37.0/24 dev tun15  proto kernel  scope link  src 10.3.37.236
10.17.100.0/24 dev wl0.1  proto kernel  scope link  src 10.17.100.1
*.*.*.*/22 dev eth0  proto kernel  scope link  src *.*.*.*
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.3.37.1 dev tun14
128.0.0.0/1 via 10.3.37.1 dev tun14
default via 107.199.24.1 dev eth0

 

[Jack Yaz]

Well I guess I should have run the commands with the VPNs up running, huh. Here's the new output:

admin@RT-AC3100:/tmp/home/root# ip rule show
0:    from all lookup local
10701:    from 10.17.100.0/24 lookup ovpnc4
10901:    from 10.17.110.0/24 lookup ovpnc5
32766:    from all lookup main
32767:    from all lookup default
admin@RT-AC3100:/tmp/home/root# ip route show
209.99.93.37 via *.*.*.* dev eth0
*.*.*.* dev eth0  proto kernel  scope link
209.99.21.37 via *.*.*.* dev eth0
10.16.0.0/24 dev tun22  proto kernel  scope link  src 10.16.0.1
10.17.89.0/24 dev br0  proto kernel  scope link  src 10.17.89.1
10.17.110.0/24 dev wl0.2  proto kernel  scope link  src 10.17.110.1
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
10.3.37.0/24 dev tun14  proto kernel  scope link  src 10.3.37.42
10.3.37.0/24 dev tun15  proto kernel  scope link  src 10.3.37.236
10.17.100.0/24 dev wl0.1  proto kernel  scope link  src 10.17.100.1
*.*.*.*/22 dev eth0  proto kernel  scope link  src *.*.*.*
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.3.37.1 dev tun14
128.0.0.0/1 via 10.3.37.1 dev tun14
default via 107.199.24.1 dev eth0

Are you using 2 VPN clients both pointing to the same port by any chance?

 

[owine]

Are you using 2 VPN clients both pointing to the same port by any chance?

I am. Both connect to port 443. Would that cause this type of issue?

 

[Jack Yaz]

I am. Both connect to port 443. Would that cause this type of issue?

Yes it can cause routing conflicts. Try one on UDP 1194 and one on TCP 443 if your provider allows that, and retry the IP checks.

 

[cmkelley]

I like it!! One question and one (eventual) feature request

Q: Is there any way to see what clients are connected to the guest wifi? Is it just a matter of 'cat'ing some file or another? I couldn't find any likely suspects in /tmp or /etc.

FR: Add ipv6 dns server identification.

 

[owine]

Yes it can cause routing conflicts. Try one on UDP 1194 and one on TCP 443 if your provider allows that, and retry the IP checks.

It worked. Thanks for your expertise. Great script, looking forward to further developments.

 

[Jack Yaz]

I like it!! One question and one (eventual) feature request

Q: Is there any way to see what clients are connected to the guest wifi? Is it just a matter of 'cat'ing some file or another? I couldn't find any likely suspects in /tmp or /etc.

FR: Add ipv6 dns server identification.

You can see all wireless clients on the System Log - > Wireless Log page. If i can find out how that works I can implement something for YazFi hopefully