YazFi issues with connecting to DNS on my LAN

[jsn2233]

Router: GT-AX11000
Firmware: 3004.388.11_0_rog

No idea why this is happening. It works for a few days then I will restart my router or come in and change a totally unrelated setting and the guest network isn't able to reach the DNS suddenly. My last router, an AC68U never had this intermittent issue, it just connected to my DNS through the guest.

I thought I resolved the issue when I realized I forgot to disable my router firewall, I disabled it and it worked for awhile, but now the issue has started again and it's so damn annoying.

The DNS is my pihole which permits all origins

Even tried to add a stupid rule that would hopefully do something but no joy:

During the time it doesn't work I can ping something like 1.1.1.1 but if i try to say nslookup google.com 192.168.50.8 - just straight errors. How can I force my guest to use the pi-hole and figure out what's causing the issue? I thought this is what YazFi was for, pinhole access for DNS? Why after power cycling my router a thousand times it starts working again?

 

[bennor]

First DO NOT disable the router firewall unless you have another firewall in place upstream from the router. Even then, it's usually not a good idea to disable the router's firewall.

YazFi does create pinhole's for DNS. There is typically no need to add extra IPTables entries to open up DNS pinholes. If you created extra IPTables DNS pinholes you should remove them and reboot the router.

It may help if you add more context to your setup.
Are you running any additional addon scripts? If so which ones?
Have you added any additional IPTable's scripting? If so what was added?
Are you using AiMesh nodes or AP nodes? If so, YazFi does not work with AiMesh or AP nodes downstream from the main router.
Are you using DNS Director? If so, how is it configured?
How have you configured the router to use Pi-Hole? Have you included the YazFi guest networks (properly) in Pi-Hole's Settings > DNS> Conditional Forwarding section?
What version of YazFi are you running?
Have you tried uninstalling then reinstalling YazFi?

There are examples of how to configure a 3004.388.x router for use with Pi-Hole. One of those general setup directions are listed in the following post:

Solved - Device not respecting DNS Director or (Yaz)DHCP Server settings

I have an Intel NUC running Pi-hole that I'm currently using as my DNS server for my network: I have a device on my IoT network that's pretty chatty (a baby monitor), and it regularly causes my Pi-hole to throw a warning that the concurrent DNS query limit is reached. I've tried both of the...

www.snbforums.com

 

[jsn2233]

First DO NOT disable the router firewall unless you have another firewall in place upstream from the router. Even then, it's usually not a good idea to disable the router's firewall.

YazFi does create pinhole's for DNS. There is typically no need to add extra IPTables entries to open up DNS pinholes. If you created extra IPTables DNS pinholes you should remove them and reboot the router.

It may help if you add more context to your setup.
Are you running any additional addon scripts? If so which ones?
Have you added any additional IPTable's scripting? If so what was added?
Are you using AiMesh nodes or AP nodes? If so, YazFi does not work with AiMesh or AP nodes downstream from the main router.
Are you using DNS Director? If so, how is it configured?
How have you configured the router to use Pi-Hole? Have you included the YazFi guest networks (properly) in Pi-Hole's Settings > DNS> Conditional Forwarding section?
What version of YazFi are you running?
Have you tried uninstalling then reinstalling YazFi?

There are examples of how to configure a 3004.388.x router for use with Pi-Hole. One of those general setup directions are listed in the following post:

Solved - Device not respecting DNS Director or (Yaz)DHCP Server settings

I have an Intel NUC running Pi-hole that I'm currently using as my DNS server for my network: I have a device on my IoT network that's pretty chatty (a baby monitor), and it regularly causes my Pi-hole to throw a warning that the concurrent DNS query limit is reached. I've tried both of the...

www.snbforums.com

Thanks for the response! I've got no idea wtf the issue is. Ok, I've enabled the firewall and removed those lines and kind of back to ground zero once again:

No other addons, only entware. I've also factory reset and left everything default except YazFi and STILL get this issue.
I did add one more rule for my other guest to work with wireguard:

Yes, I do have an AP node but I'm not trying to run my guest through that if that's what you mean? I only added an AP last week and was having this issue before then, ever since I got this router in December.

The issue persists whether or not I have DNS Director on. I added it back in the other day, desperate to try and fix this issue:

The router uses the pi-hole perfectly. The guests struggle for some reason. I never had to configure conditional forwarding on my pihole before, it just worked on last router. What do I change here?:

Yes I have tried reinstalling and factory resetting with minimal settings changes and the issue persists. I read another comment about the router firewall causing it and decided to disable it and that's when it actually started working, just intermittently.

Thanks for that post about 3004.388.x routers, will check that out ASAP. Any idea what I'm dong wrong?

Edit: Also using the latest version of YazFi.

 

[dave14305]

Post all the iptables rules. Redact your WAN IP.

iptables-save -c

 

[bennor]

No other addons, only entware. I've also factory reset and left everything default except YazFi and STILL get this issue.
I did add one more rule for my other guest to work with wireguard:

Do you have VPN enabled while you are trying to ping?
Are you pinging from the YazFi client? Can you ping 1.1.1.1 from the router GUI interface?
Where do you have the Pi-Hole IP Address input for the DNS on the router? In the WAN DNS fields (not recomended) or in the LAN DHCP DNS fields?
What DNS server's is the Pi-Hole configured to use? Are you using Unbound in addition to Pi-Hole?
What device is running the Pi-Hole?

 

[jsn2233]

Post all the iptables rules. Redact your WAN IP.

iptables-save -c

Thanks man!

# Completed on Thu Jan 22 00:12:07 2026
# Generated by iptables-save v1.4.15 on Thu Jan 22 00:12:07 2026
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1113:180369]
:ACCESS_RESTRICTION - [0:0]
:DNSFILTER_DOT - [0:0]
:FUPNP - [0:0]
:IControls - [0:0]
:INPUT_ICMP - [0:0]
:INPUT_PING - [0:0]
:IPSEC_DROP_SUBNET_ICMP - [0:0]
:IPSEC_STRONGSWAN - [0:0]
:OUTPUT_DNS - [0:0]
:OUTPUT_IP - [0:0]
:OVPNCF - [0:0]
:OVPNCI - [0:0]
:OVPNSF - [0:0]
:OVPNSI - [0:0]
:PControls - [0:0]
:PTCSRVLAN - [0:0]
:PTCSRVWAN - [0:0]
:SECURITY - [0:0]
:VPNCF - [0:0]
:VPNCI - [0:0]
:WGCF - [0:0]
:WGCI - [0:0]
:WGNPControls - [0:0]
:WGSF - [0:0]
:WGSI - [0:0]
:YazFiDNSFILTER_DOT - [0:0]
:YazFiFORWARD - [0:0]
:YazFiINPUT - [0:0]
:YazFiREJECT - [0:0]
:default_block - [0:0]
:logaccept - [0:0]
:logdrop - [0:0]
:logdrop_dns - [0:0]
:logdrop_ip - [0:0]
[916:201034] -A INPUT -j YazFiINPUT
[0:0] -A INPUT -i eth0 -p igmp -j ACCEPT
[3:160] -A INPUT -p icmp -m icmp --icmp-type 8 -j INPUT_PING
[1265:388616] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
[2:104] -A INPUT -m state --state INVALID -j DROP
[851:341284] -A INPUT ! -i br0 -j PTCSRVWAN
[198:45404] -A INPUT -i br0 -j PTCSRVLAN
[0:0] -A INPUT ! -i lo -p tcp -m tcp --dport 5152 -j DROP
[198:45404] -A INPUT -i br0 -m state --state NEW -j ACCEPT
[810:337273] -A INPUT -i lo -m state --state NEW -j ACCEPT
[0:0] -A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
[0:0] -A INPUT -p icmp -j INPUT_ICMP
[41:4011] -A INPUT -j WGSI
[41:4011] -A INPUT -j WGCI
[36:3655] -A INPUT -j OVPNSI
[36:3655] -A INPUT -j OVPNCI
[36:3655] -A INPUT -j DROP
[0:0] -A FORWARD -d 224.0.0.0/4 -i eth0 -j ACCEPT
[689:229182] -A FORWARD -j IPSEC_DROP_SUBNET_ICMP
[689:229182] -A FORWARD -j IPSEC_STRONGSWAN
[0:0] -A FORWARD -p tcp -m tcp --dport 853 -j YazFiDNSFILTER_DOT
[400:111049] -A FORWARD -j YazFiFORWARD
[634:202474] -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
[55:26708] -A FORWARD -j WGSF
[55:26708] -A FORWARD -j OVPNSF
[0:0] -A FORWARD ! -i br0 -o eth0 -j DROP
[0:0] -A FORWARD -i br0 -o br0 -j ACCEPT
[0:0] -A FORWARD -m state --state INVALID -j DROP
[9:652] -A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
[0:0] -A FORWARD -i eth0 -o br0 -j ACCEPT
[0:0] -A FORWARD -i br+ -p tcp -m tcp --dport 853 -j DNSFILTER_DOT
[46:26056] -A FORWARD -j WGCF
[20:17334] -A FORWARD -j OVPNCF
[20:17334] -A FORWARD -j VPNCF
[20:17334] -A FORWARD -i br0 -j ACCEPT
[0:0] -A FORWARD -j DROP
[2:134] -A OUTPUT -p udp -m udp --dport 53 -m u32 --u32 "0x0>>0x16&0x3c@0x8>>0xf&0x1=0x0" -j OUTPUT_DNS
[0:0] -A OUTPUT -p tcp -m tcp --dport 53 -m u32 --u32 "0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x8>>0xf&0x1=0x0" -j OUTPUT_DNS
[2763:751661] -A OUTPUT -j OUTPUT_IP
[0:0] -A DNSFILTER_DOT -m mac --mac-source D8:3A:DD:5A:02:9P -j RETURN
[0:0] -A DNSFILTER_DOT ! -d 192.168.50.8/32 -j REJECT --reject-with icmp-port-unreachable
[0:0] -A FUPNP -d 192.168.50.75/32 -p tcp -m tcp --dport 22000 -j ACCEPT
[0:0] -A INPUT_ICMP -p icmp -m icmp --icmp-type 8 -j RETURN
[0:0] -A INPUT_ICMP -p icmp -m icmp --icmp-type 13 -j RETURN
[0:0] -A INPUT_ICMP -p icmp -j ACCEPT
[1:40] -A INPUT_PING -i eth0 -p icmp -j DROP
[0:0] -A OUTPUT_DNS -m string --hex-string "|10706f697579747975696f706b6a666e6603636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
[0:0] -A OUTPUT_DNS -m string --hex-string "|0d72666a656a6e666a6e65666a6503636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
[0:0] -A OUTPUT_DNS -m string --hex-string "|1131306166646d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
[0:0] -A OUTPUT_DNS -m string --hex-string "|0f376d667364666173646d6b676d726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
[0:0] -A OUTPUT_DNS -m string --hex-string "|0d386d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
[0:0] -A OUTPUT_DNS -m string --hex-string "|0f3966646d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
[0:0] -A OUTPUT_DNS -m string --hex-string "|1265666274686d6f6975796b6d6b6a6b6a677403636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
[0:0] -A OUTPUT_DNS -m string --hex-string "|086861636b7563647403636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
[0:0] -A OUTPUT_DNS -m string --hex-string "|076c696e77756469056633333232036e657400|" --algo bm --to 65535 --icase -j logdrop_dns
[0:0] -A OUTPUT_DNS -m string --hex-string "|0f6c6b6a68676664736174727975696f03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
[0:0] -A OUTPUT_DNS -m string --hex-string "|0b6d6e627663787a7a7a313203636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
[0:0] -A OUTPUT_DNS -m string --hex-string "|077131313133333303746f7000|" --algo bm --to 65535 --icase -j logdrop_dns
[0:0] -A OUTPUT_DNS -m string --hex-string "|057371353230056633333232036e657400|" --algo bm --to 65535 --icase -j logdrop_dns
[0:0] -A OUTPUT_DNS -m string --hex-string "|077563746b6f6e6503636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
[0:0] -A OUTPUT_DNS -m string --hex-string "|0e7a786376626d6e6e666a6a66777103636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
[0:0] -A OUTPUT_DNS -m string --hex-string "|0a65756d6d6167766e627003636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
[0:0] -A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN
[0:0] -A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
[0:0] -A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
[0:0] -A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j DROP
[0:0] -A SECURITY -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j RETURN
[0:0] -A SECURITY -p icmp -m icmp --icmp-type 8 -j DROP
[0:0] -A SECURITY -j RETURN
[2:120] -A WGCF -o wgc2 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
[26:8722] -A WGCF -o wgc2 -j ACCEPT
[0:0] -A WGCF -i wgc2 -j DROP
[5:356] -A WGCI -i wgc2 -j DROP
[0:0] -A YazFiFORWARD -i wgc1 -o wl1.2 -m state --state RELATED,ESTABLISHED -j ACCEPT
[0:0] -A YazFiFORWARD -i wl1.2 -o wgc1 -j ACCEPT
[0:0] -A YazFiFORWARD -s 192.168.50.8/32 -o wl1.1 -p udp -m udp --sport 53 -j ACCEPT
[0:0] -A YazFiFORWARD -d 192.168.50.8/32 -i wl1.1 -p udp -m udp --dport 53 -j ACCEPT
[0:0] -A YazFiFORWARD -s 192.168.50.8/32 -o wl1.1 -p tcp -m tcp --sport 53 -j ACCEPT
[0:0] -A YazFiFORWARD -d 192.168.50.8/32 -i wl1.1 -p tcp -m tcp --dport 53 -j ACCEPT
[0:0] -A YazFiFORWARD ! -i eth0 -o wl1.1 -j YazFiREJECT
[0:0] -A YazFiFORWARD -i wl1.1 ! -o eth0 -j YazFiREJECT
[0:0] -A YazFiFORWARD -i wl1.1 -m comment --comment "YazFi 5GHz 1" -j ACCEPT
[0:0] -A YazFiINPUT -i wl1.1 -p udp -m multiport --dports 67,123 -j ACCEPT
[0:0] -A YazFiINPUT -i wl1.1 -p icmp -j ACCEPT
[7:1649] -A YazFiINPUT -i wl1.1 -j YazFiREJECT
[7:1649] -A YazFiREJECT -j REJECT --reject-with icmp-port-unreachable
[0:0] -A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
[0:0] -A logaccept -j ACCEPT
[0:0] -A logdrop -m state --state NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
[0:0] -A logdrop -j DROP
[0:0] -A logdrop_dns -j LOG --log-prefix "DROP_DNS " --log-tcp-sequence --log-tcp-options --log-ip-options
[0:0] -A logdrop_dns -j DROP
[0:0] -A logdrop_ip -j LOG --log-prefix "DROP_IP " --log-tcp-sequence --log-tcp-options --log-ip-options
[0:0] -A logdrop_ip -j DROP
COMMIT

 

[dave14305]

Thanks man!

You’re missing some of the output, specifically from the nat table.
Did you run your nslookup test before posting the output? Please do that.

 

[jsn2233]

Do you have VPN enabled while you are trying to ping?

Nope, no VPN on the guest.

Are you pinging from the YazFi client? Can you ping 1.1.1.1 from the router GUI interface?

Yes, that is from the YazFi client. The router can do it no problem.

Where do you have the Pi-Hole IP Address input for the DNS on the router? In the WAN DNS fields (not recomended) or in the LAN DHCP DNS fields?
What DNS server's is the Pi-Hole configured to use? Are you using Unbound in addition to Pi-Hole?
What device is running the Pi-Hole?

I have them in LAN. I use Quad 9 for WAN:

What DNS server's is the Pi-Hole configured to use? Are you using Unbound in addition to Pi-Hole?

No, I don't have unbound I use Quad 9

What device is running the Pi-Hole?

It's an umbrel - just a pihole with a easy to use docker container firmware. It works good for the LAN, just not guests.

 

[jsn2233]

There are examples of how to configure a 3004.388.x router for use with Pi-Hole. One of those general setup directions are listed in the following post:

Solved - Device not respecting DNS Director or (Yaz)DHCP Server settings

I have an Intel NUC running Pi-hole that I'm currently using as my DNS server for my network: I have a device on my IoT network that's pretty chatty (a baby monitor), and it regularly causes my Pi-hole to throw a warning that the concurrent DNS query limit is reached. I've tried both of the...

www.snbforums.com

Also, done all your steps from here and nothing so far

 

[jsn2233]

You’re missing some of the output, specifically from the nat table.
Did you run your nslookup test before posting the output? Please do that.

Think I'm a bit confused, am I just SSHing into my router after running that? I just did again and the output is the same? Am I doing it wrong?

 

[dave14305]

Think I'm a bit confused, am I just SSHing into my router after running that? I just did again and the output is the same? Am I doing it wrong?

Try running:

iptables -t nat -nvL

 

[jsn2233]

Try running:

iptables -t nat -nvL

Ok man

Chain PREROUTING (policy ACCEPT 518 packets, 83380 bytes)
 pkts bytes target     prot opt in     out     source               destination        
   67  4060 YazFiDNSFILTER  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
  247 18021 YazFiDNSFILTER  udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
   67  4060 DNSVPN7    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
  249 18172 DNSVPN7    udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     all  --  eth0   *       0.0.0.0/0            x.x.x.x/4        
  106 11268 GAME_VSERVER  all  --  *      *       0.0.0.0/0            x.x.x.x        
  106 11268 VSERVER    all  --  *      *       0.0.0.0/0            x.x.x.x        
    9   682 DNSFILTER  udp  --  br+    *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 DNSFILTER  tcp  --  br+    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53

Chain INPUT (policy ACCEPT 63 packets, 9243 bytes)
 pkts bytes target     prot opt in     out     source               destination        

Chain OUTPUT (policy ACCEPT 75 packets, 13036 bytes)
 pkts bytes target     prot opt in     out     source               destination        

Chain POSTROUTING (policy ACCEPT 45 packets, 7914 bytes)
 pkts bytes target     prot opt in     out     source               destination        
    8  1504 MASQUERADE  all  --  *      wl1.1   192.168.5.0/24       192.168.5.0/24       /* YazFi 5GHz 1 */
  356 30793 MASQUERADE  all  --  *      wgc2   !x.x.x.17         0.0.0.0/0          
   66 52981 MASQUERADE  all  --  *      eth0   !x.x.x.67           0.0.0.0/0          
  534 35676 MASQUERADE  all  --  *      br0     192.168.50.0/24      192.168.50.0/24    

Chain DNSFILTER (2 references)
 pkts bytes target     prot opt in     out     source               destination        
    9   682 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            MAC D8:3A:DD:5A:02:D1
    0     0 DNAT       all  --  *      *       0.0.0.0/0            0.0.0.0/0            to:192.168.50.8

Chain DNSVPN7 (2 references)
 pkts bytes target     prot opt in     out     source               destination        
    0     0 RETURN     all  --  *      *       192.168.50.153       0.0.0.0/0          
  126  9752 DNAT       all  --  *      *       192.168.50.0/24      0.0.0.0/0            to:x.x.x.x

Chain GAME_VSERVER (1 references)
 pkts bytes target     prot opt in     out     source               destination        

Chain LOCALSRV (0 references)
 pkts bytes target     prot opt in     out     source               destination        

Chain MAPE (0 references)
 pkts bytes target     prot opt in     out     source               destination        

Chain PCREDIRECT (0 references)
 pkts bytes target     prot opt in     out     source               destination        

Chain PUPNP (0 references)
 pkts bytes target     prot opt in     out     source               destination        
    0     0 MASQUERADE  tcp  --  *      *       192.168.50.75        0.0.0.0/0            tcp spt:22000 masq ports: 28516

Chain VSERVER (1 references)
 pkts bytes target     prot opt in     out     source               destination        

Chain VUPNP (0 references)
 pkts bytes target     prot opt in     out     source               destination        
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:28516 to:192.168.50.75:22000

Chain YazFiDNSFILTER (2 references)
 pkts bytes target     prot opt in     out     source               destination

 

[dave14305]

Ok man

I’ve never used YazFi, so what wireless interface is your test client connected to? wl1.1 or wl1.2?

[0:0] -A YazFiFORWARD -s 192.168.50.8/32 -o wl1.1 -p udp -m udp --sport 53 -j ACCEPT [0:0] -A YazFiFORWARD -d 192.168.50.8/32 -i wl1.1 -p udp -m udp --dport 53 -j ACCEPT [0:0] -A YazFiFORWARD -s 192.168.50.8/32 -o wl1.1 -p tcp -m tcp --sport 53 -j ACCEPT [0:0] -A YazFiFORWARD -d 192.168.50.8/32 -i wl1.1 -p tcp -m tcp --dport 53 -j ACCEPT

there are zero hits on these rules. So something seems wrong.

 

[jsn2233]

I’ve never used YazFi, so what wireless interface is your test client connected to? wl1.1 or wl1.2?

there are zero hits on these rules. So something seems wrong.

Sorry bro, it's wl1.1 guest I want to connect to my pihole. wl1.2 is a different one I don't really use.

I just don't understand what is blocking it?

 

[dave14305]

67 4060 DNSVPN7 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
249 18172 DNSVPN7 udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53

I might suspect the VPN interaction.

Try to install tcpdump from Entware.

opkg update
opkg install tcpdump
tcpdump -nvpi br0 port 53 and host 192.168.50.8
tcpdump -nvpi wl1.1 port 53

The first tcpdump will show a lot of queries besides the guest queries, possibly. Just looking for evidence your nslookup test is coming in wl1.1 and going out br0.
Or try this more generic command to watch all interfaces.

tcpdump -i any -npv port 53

 

[jsn2233]

I might suspect the VPN interaction.

Try to install tcpdump from Entware.

opkg update
opkg install tcpdump
tcpdump -nvp[i br0 port 53 and host 192.168.50.8
tcpdump -nvpi wl1.1 port 53/CODE]
The first tcpdump will show a lot of queries besides the guest queries, possibly. Just looking for evidence your nslookup test is coming in wl1.1 and going out br0.
Or try this more generic command to watch all interfaces.
[CODE]tcpdump -i any -npv port 53

Hi, sorry about late reply just got home from work

/tmp/home/root# tcpdump -i any -npv port 53
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
19:24:53.643563 wl1.1 In  IP (tos 0x0, ttl 64, id 60386, offset 0, flags [none], proto UDP (17), length 56)
    192.168.5.18.51879 > 192.168.50.8.53: 17535+ A? google.com. (28)
19:24:58.708552 wl1.1 In  IP (tos 0x0, ttl 64, id 42379, offset 0, flags [none], proto UDP (17), length 56)
    192.168.5.18.38418 > 192.168.50.8.53: 17535+ A? google.com. (28)
19:25:03.709869 wl1.1 In  IP (tos 0x0, ttl 64, id 6878, offset 0, flags [none], proto UDP (17), length 56)
    192.168.5.18.53164 > 192.168.50.8.53: 17535+ A? google.com. (28)
^C
61 packets captured
69 packets received by filter
0 packets dropped by kernel

This is only the nslookup to google, I removed all the additional stuff because I'm not quite sure what's sensitive or not. So you think the VPN I use is blocking the dns lookup somehow? How is it doing this if the guest network isn't even using the VPN?




EDIT: Also not sure why these commands didn't show anything?:

tcpdump -nvpi br0 port 53 and host 192.168.50.8
tcpdump -nvpi wl1.1 port 53

The issue was, I believe, that I wcan't use my guest network to SSH into my router as it doesn't have this access... maybe? I'm not sure. I ran the command on my phone in Termux whilst on the guest network then ran the tcpdump from my computer.

 

[jsn2233]

Wow, just turned my VPN off and the guest network immediately worked with the DNS. Is this some kind of bug? Doesn't make sense to me anyways. Why would a wireguard client not even connected to the guest block it reaching my DNS?

Turned the VPN on and it still works. I guess it has something to do with which one starts up first? Maybe I will just have to disable VPN in order to to get the DNS up and running first, then enable the VPN again. Should I report this as a bug?

 

[bennor]

EDIT: Also not sure why these commands didn't show anything?:

tcpdump -nvp[i br0 port 53 and host 192.168.50.8
tcpdump -nvpi wl1.1 port 53

You have a typo in the first tcpdump line. It should be:
tcpdump -nvpi br0 port 53 and host 192.168.50.8
Running tcpdump assumes one has installed tcpdump.

opkg update
opkg install tcpdump

 

[jsn2233]

You have a typo in the first tcpdump line. It should be:
tcpdump -nvpi br0 port 53 and host 192.168.50.8
Running tcpdump assumes one has installed tcpdump.

opkg update
opkg install tcpdump

Yeah sorry, I just copied the command wrong when I was writing the reply, I used it in the command line correctly.

 

[jsn2233]

Hmm I just thought about it, could any of these rules be a part of the reason?

Also the device my pihole is on is running through the same VPN. Could this cause an issue with routing to/from the guest?