What's new

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

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

ok. You would have experienced the same thing if using dnsfilter. The purpose is to guarantee that your dns traffic goes to a particular server, so if you took the server down, it's working as designed.
I take it the main WiFi (not the guests) on the Asus/Merlin firmware does not use dnsfilter? Because taking down the DNS1 server doesn't block wifi clients from accessing the main wifi like it does when clients access the guest wifi. Ether that or those clients that can access are storing the DNS info and will make the connection even if those servers are down.
 
I take it the main WiFi (not the guests) on the Asus/Merlin firmware does not use dnsfilter? Because taking down the DNS1 server doesn't block wifi clients from accessing the main wifi like it does when clients access the guest wifi. Ether that or those clients that can access are storing the DNS info and will make the connection even if those servers are down.
It should. The iptables rules effectively intercept traffic on port 53 and send it to the specified server
 
Hello
Just trying out this script, works well as far as I can tell.

I'm a bit new to all this. Is there a way of the Yazfi subnet being able to see the main one? My use case is to have a wifi that skips the vpn and one that goes via it.

Thanks
 
Hello
Just trying out this script, works well as far as I can tell.

I'm a bit new to all this. Is there a way of the Yazfi subnet being able to see the main one? My use case is to have a wifi that skips the vpn and one that goes via it.

Thanks

Look at post 2.
 
I’ve set _LANACCESS to true and _CLIENTISOLATION to false, is there anything else I’m missing?

My laptop can’t access computer shares on the main network when on Yazfi network.
Thanks
Can you run the diagnostics please, and PM me the passphrase? You can rename the encrypted archive with a .txt extension if it gets blocked

EDIT: Firstly, Windows (I'm assuming) is probably blocking different subnets from accessing the shares. You'll need to amend the Windows FIrewall rules to include the YazFi subnet
 
Can you run the diagnostics please, and PM me the passphrase? You can rename the encrypted archive with a .txt extension if it gets blocked

EDIT: Firstly, Windows (I'm assuming) is probably blocking different subnets from accessing the shares. You'll need to amend the Windows FIrewall rules to include the YazFi subnet

Thanks for your reply I will PM the diagnostics. Would that be windows firewall on the machine hosting the share? Thanks again
 
I have my Pihole hosted in GCP and I access it via a VPN on my router. Is there a way to split VPN with Yazfi so that my clients on the guest network can reach my Pihole over the VPN but all other traffic goes out over my local ISP rather than the VPN?
 
I have my Pihole hosted in GCP and I access it via a VPN on my router. Is there a way to split VPN with Yazfi so that my clients on the guest network can reach my Pihole over the VPN but all other traffic goes out over my local ISP rather than the VPN?
Not currently. I believe someone on this forum has a script in the works to beef up policy routing, at which time I can look to integrate YazFi
 
Not currently. I believe someone on this forum has a script in the works to beef up policy routing, at which time I can look to integrate YazFi
I figured the work around... let Yazfi do its thing. Then, delete the custom route Yazi created and create my own custom route that only routes to the Pihole IP. The only inconvenience is that after every reboot or run of Yazfi I have to do this. Not a huge deal as a reboot is not frequent - but maybe a feature request for long term. Thanks!
 
I figured the work around... let Yazfi do its thing. Then, delete the custom route Yazi created and create my own custom route that only routes to the Pihole IP. The only inconvenience is that after every reboot or run of Yazfi I have to do this. Not a huge deal as a reboot is not frequent - but maybe a feature request for long term. Thanks!
Surely that is sending all traffic to the PiHole, rather than just DNS?
 
Surely that is sending all traffic to the PiHole, rather than just DNS?


Negative. YazFi creates a route like the following in the Client VPN config:

Source: 192.168.180.0/24
Destination: 0.0.0.0
iface: VPN

I delete that route and create a new one like:

Source: 192.168.180.0/24
Destination: 10.8.0.1 < Pihole IP on the other side of the tunnel
iface: VPN

I just went from a catch all route to a singular IP. At least it seems to work. I think the router may be creating a conditional route. Lemmie dump a routing table to confirm. I assume though YazFi has created a giant allow in IPTables which is fine in this case as I have only the Pihole on the other end. This may not be ideal for folks that may have other goodies they want to protect on the other side of the VPN.

YazFi then overwrites my route upon each script run and I just tweak the route back the way I want it.

EDIT: Hrm,

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
75.187.48.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun11
192.168.180.0 0.0.0.0 255.255.255.0 U 0 0 0 wl0.1
75.187.48.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 75.187.48.1 0.0.0.0 UG 0 0 0 eth0

So the route is somewhere else.... and OpenVPN is not intuitive on how to dump its client routes.

EDIT 2: More hrm

Chain YazFiFORWARD (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT udp -- 10.8.0.1 anywhere udp spt:domain
ACCEPT udp -- anywhere 10.8.0.1 udp dpt:domain
ACCEPT tcp -- 10.8.0.1 anywhere tcp spt:domain
ACCEPT tcp -- anywhere 10.8.0.1 tcp dpt:domain
YazFiREJECT all -- anywhere anywhere
YazFiREJECT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
 
Last edited:
Negative. YazFi creates a route like the following in the Client VPN config:

Source: 192.168.180.0/24
Destination: 0.0.0.0
iface: VPN

I delete that route and create a new one like:

Source: 192.168.180.0/24
Destination: 10.8.0.1 < Pihole IP on the other side of the tunnel
iface: VPN

I just went from a catch all route to a singular IP. At least it seems to work. I think the router may be creating a conditional route. Lemmie dump a routing table to confirm. I assume though YazFi has created a giant allow in IPTables which is fine in this case as I have only the Pihole on the other end. This may not be ideal for folks that may have other goodies they want to protect on the other side of the VPN.

YazFi then overwrites my route upon each script run and I just tweak the route back the way I want it.

EDIT: Hrm,

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
75.187.48.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun11
192.168.180.0 0.0.0.0 255.255.255.0 U 0 0 0 wl0.1
75.187.48.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 75.187.48.1 0.0.0.0 UG 0 0 0 eth0

So the route is somewhere else.... and OpenVPN is not intuitive on how to dump its client routes.

EDIT 2: More hrm

Chain YazFiFORWARD (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT udp -- 10.8.0.1 anywhere udp spt:domain
ACCEPT udp -- anywhere 10.8.0.1 udp dpt:domain
ACCEPT tcp -- 10.8.0.1 anywhere tcp spt:domain
ACCEPT tcp -- anywhere 10.8.0.1 tcp dpt:domain
YazFiREJECT all -- anywhere anywhere
YazFiREJECT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
The second output, is that with just -L? Can you try either with -nvL or - S instead? That should show the interfaces
 
The second output, is that with just -L? Can you try either with -nvL or - S instead? That should show the interfaces
Indeed, that was -L. Here is -S

-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N ACCESS_RESTRICTION
-N DNSFILTER_DOT
-N FUPNP
-N INPUT_ICMP
-N NSFW
-N OVPN
-N PControls
-N PTCSRVLAN
-N PTCSRVWAN
-N SECURITY
-N YazFiFORWARD
-N YazFiINPUT
-N YazFiREJECT
-N default_block
-N logaccept
-N logdrop
-N other2wan
-A INPUT -j YazFiINPUT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT ! -i br0 -j PTCSRVWAN
-A INPUT -i br0 -j PTCSRVLAN
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -m state --state NEW -j OVPN
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -d 192.168.178.1/32 -p tcp -m conntrack --ctstate DNAT -m tcp --dport 8443 -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -j DROP
-A FORWARD -j YazFiFORWARD
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD ! -i br0 -o eth0 -j other2wan
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -i eth0 -j SECURITY
-A FORWARD -j NSFW
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -m state --state NEW -j OVPN
-A FORWARD -i br0 -j ACCEPT
-A OVPN -i tun11 -j ACCEPT
-A PControls -j ACCEPT
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j DROP
-A SECURITY -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j RETURN
-A SECURITY -p icmp -m icmp --icmp-type 8 -j DROP
-A SECURITY -j RETURN
-A YazFiFORWARD -i tun11 -o wl0.1 -j ACCEPT
-A YazFiFORWARD -i wl0.1 -o tun11 -j ACCEPT
-A YazFiFORWARD -s 10.8.0.1/32 -o wl0.1 -p udp -m udp --sport 53 -j ACCEPT
-A YazFiFORWARD -d 10.8.0.1/32 -i wl0.1 -p udp -m udp --dport 53 -j ACCEPT
-A YazFiFORWARD -s 10.8.0.1/32 -o wl0.1 -p tcp -m tcp --sport 53 -j ACCEPT
-A YazFiFORWARD -d 10.8.0.1/32 -i wl0.1 -p tcp -m tcp --dport 53 -j ACCEPT
-A YazFiFORWARD -i wl0.1 ! -o eth0 -j YazFiREJECT
-A YazFiFORWARD ! -i eth0 -o wl0.1 -j YazFiREJECT
-A YazFiFORWARD -i wl0.1 -j ACCEPT
-A YazFiINPUT -i wl0.1 -p udp -m multiport --dports 137,138 -j ACCEPT
-A YazFiINPUT -i wl0.1 -p udp -m multiport --dports 67,123 -j ACCEPT
-A YazFiINPUT -i wl0.1 -p icmp -j ACCEPT
-A YazFiINPUT -i wl0.1 -j YazFiREJECT
-A YazFiREJECT -j REJECT --reject-with icmp-port-unreachable
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -m state --state NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -j DROP
-A other2wan -i tun+ -j RETURN
-A other2wan -j DROP
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Staff online

Top