SomeWhereOverTheRainBow
Part of the Furniture
reboot phone or device. or run a cleaner.How do you "refresh your DNS before testing on Android"
Thanks
reboot phone or device. or run a cleaner.How do you "refresh your DNS before testing on Android"
Thanks
If you want to have logging enabled with no other benefits that Diversion offers, then installing Diversion would be overkill IMO.@thelonelycoder can this be used to make sure dnsmasq with logging is correctly setup as not sure mine is?
Thanks
log-async
log-queries
log-facility=/path/to/your/usb-device/dnsmasq.log
admin@RT-AC68U-7BA8:/tmp/home/root# cat /jffs/configs/dnsmasq.conf.add
interface=br1
dhcp-range=br1,192.168.20.3,192.168.20.149,255.255.255.0,86400s
dhcp-option=br1,3,192.168.20.1
dhcp-option=br1,6,192.168.20.1
# Allow BR1 to access WAN
iptables -D FORWARD -i br1 -m state --state NEW -j ACCEPT >/dev/null 2>&1
iptables -I FORWARD -i br1 -m state --state NEW -j ACCEPT
# Prevent BR1 from accessing BR0 and vice versa
iptables -D FORWARD -i br1 -o br0 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP
iptables -D FORWARD -i br0 -o br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br0 -o br1 -m state --state NEW -j DROP
#
iptables -D INPUT -i br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I INPUT -i br1 -m state --state NEW -j DROP
# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p tcp --dport 53 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p tcp --dport 53 -j ACCEPT
# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT
Try moving your INPUT ... DROP commands AFTER the INPUT ... ACCEPT commands.Is Diversion supposed to work with Vlans?
I have a main AC-RT68U router connected to a secondary AC-R68U acting just as AP. Since you cannot use guest networks properly when in AP mode, I created a vlan instead for the guest networks (using the same idea as here https://www.snbforums.com/threads/expand-the-guest-network-to-two-merlin-routers.61231/)
Basically all the packets from the devices connected to the guest networks on the AP are tagged vlan101 and using br1 on the main router, and the main router is using dnsmasq to assign dhcp addresses in the 192.168.20.x range (main addresses are 192.168.1.x) with
Code:admin@RT-AC68U-7BA8:/tmp/home/root# cat /jffs/configs/dnsmasq.conf.add interface=br1 dhcp-range=br1,192.168.20.3,192.168.20.149,255.255.255.0,86400s dhcp-option=br1,3,192.168.20.1 dhcp-option=br1,6,192.168.20.1
and a change in iptables as follows
Code:# Allow BR1 to access WAN iptables -D FORWARD -i br1 -m state --state NEW -j ACCEPT >/dev/null 2>&1 iptables -I FORWARD -i br1 -m state --state NEW -j ACCEPT # Prevent BR1 from accessing BR0 and vice versa iptables -D FORWARD -i br1 -o br0 -m state --state NEW -j DROP >/dev/null 2>&1 iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP iptables -D FORWARD -i br0 -o br1 -m state --state NEW -j DROP >/dev/null 2>&1 iptables -I FORWARD -i br0 -o br1 -m state --state NEW -j DROP # iptables -D INPUT -i br1 -m state --state NEW -j DROP >/dev/null 2>&1 iptables -I INPUT -i br1 -m state --state NEW -j DROP # Allow DNSMASQ to distribute IP addresses for br1. iptables -D INPUT -i br1 -p tcp --dport 53 -j ACCEPT >/dev/null 2>&1 iptables -I INPUT -i br1 -p tcp --dport 53 -j ACCEPT # Allow DNSMASQ to distribute IP addresses for br1. iptables -D INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT >/dev/null 2>&1 iptables -I INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT
I have to admit that the IPTABLES part is a bit of a black magic to me. I understand everything else just fine, but I simply copied the IPTABLES part (and I also saw someone else using EBTABLES instead). I was also surprised to see that the devices on the guest network also use Diversion and Diversion blocks everything in my block list even for guest devices
For a while everything worked just fine, but I started noticing that some webpages are not loading properly when on the guest network. Disabling Diversion then re-enabling it, seems to fix things for a while. But I don't know if it's because of Diversion or simply because disabling and re-enabling Diversion also restarts a few services
Is my setup even supposed to work, given that Diversion also uses dnsmasq? I do see in dnsmasq.log all the requests coming from the clients on 192.168.20.x, and those seem to be redirected properly or blocked as appropriate... Is there anything I can to to help troubleshoot the connectivity problems?
I tried, but I think that in that case it drops every TCP packet, at least according toTry moving your INPUT ... DROP commands AFTER the INPUT ... ACCEPT commands.
admin@RT-AC68U-7BA8:/tmp/home/root# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
448 47229 DROP all -- br1 any anywhere anywhere state NEW
19 1824 ACCEPT udp -- br1 any anywhere anywhere multiport dports domain,bootps
0 0 ACCEPT tcp -- br1 any anywhere anywhere tcp dpt:domain
# Allow BR1 to access WAN
iptables -D FORWARD -i br1 -m state --state NEW -j ACCEPT >/dev/null 2>&1
iptables -I FORWARD -i br1 -m state --state NEW -j ACCEPT
# Prevent BR1 from accessing BR0 and vice versa
iptables -D FORWARD -i br1 -o br0 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP
iptables -D FORWARD -i br0 -o br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br0 -o br1 -m state --state NEW -j DROP
# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p tcp --dport 53 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p tcp --dport 53 -j ACCEPT
# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT
#
iptables -D INPUT -i br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I INPUT -i br1 -m state --state NEW -j DROP
Using -I means you should use the command you want at the top last, so you want ACCEPT to be "inserted" after the drop rulesTry moving your INPUT ... DROP commands AFTER the INPUT ... ACCEPT commands.
Sorry, my mistake. I missed that you were inserting with -I instead of appending with -A. Put it back the way you had and post the iptables -nvL again.I tried, but I think that in that case it drops every TCP packet, at least according to
Code:admin@RT-AC68U-7BA8:/tmp/home/root# iptables -L -v Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 448 47229 DROP all -- br1 any anywhere anywhere state NEW 19 1824 ACCEPT udp -- br1 any anywhere anywhere multiport dports domain,bootps 0 0 ACCEPT tcp -- br1 any anywhere anywhere tcp dpt:domain
To be clear, I tried:
and in that case I can't even get an IP address on the guest network/vlanCode:# Allow BR1 to access WAN iptables -D FORWARD -i br1 -m state --state NEW -j ACCEPT >/dev/null 2>&1 iptables -I FORWARD -i br1 -m state --state NEW -j ACCEPT # Prevent BR1 from accessing BR0 and vice versa iptables -D FORWARD -i br1 -o br0 -m state --state NEW -j DROP >/dev/null 2>&1 iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP iptables -D FORWARD -i br0 -o br1 -m state --state NEW -j DROP >/dev/null 2>&1 iptables -I FORWARD -i br0 -o br1 -m state --state NEW -j DROP # Allow DNSMASQ to distribute IP addresses for br1. iptables -D INPUT -i br1 -p tcp --dport 53 -j ACCEPT >/dev/null 2>&1 iptables -I INPUT -i br1 -p tcp --dport 53 -j ACCEPT # Allow DNSMASQ to distribute IP addresses for br1. iptables -D INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT >/dev/null 2>&1 iptables -I INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT # iptables -D INPUT -i br1 -m state --state NEW -j DROP >/dev/null 2>&1 iptables -I INPUT -i br1 -m state --state NEW -j DROP
Here it is:Sorry, my mistake. I missed that you were inserting with -I instead of appending with -A. Put it back the way you had and post the iptables -nvL again.
admin@RT-AC68U-7BA8:/tmp/home/root# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
179 13288 ACCEPT udp -- br1 * 0.0.0.0/0 0.0.0.0/0 multiport dports 53,67
0 0 ACCEPT tcp -- br1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
639 52485 DROP all -- br1 * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 INPUT_PING icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
6001 675K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
149 11372 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
1323 370K PTCSRVWAN all -- !br0 * 0.0.0.0/0 0.0.0.0/0
2020 455K PTCSRVLAN all -- br0 * 0.0.0.0/0 0.0.0.0/0
2020 455K ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW
1176 340K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 state NEW
147 29685 OVPN all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW
4 1342 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
0 0 INPUT_ICMP icmp -- * * 0.0.0.0/0 0.0.0.0/0
143 28343 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- br0 br1 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 DROP all -- br1 br0 0.0.0.0/0 0.0.0.0/0 state NEW
305 72848 ACCEPT all -- br1 * 0.0.0.0/0 0.0.0.0/0 state NEW
40107 31M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
35 2873 other2wan all -- !br0 eth0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- br0 br0 0.0.0.0/0 0.0.0.0/0
14 1344 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
254 66882 NSFW all -- * * 0.0.0.0/0 0.0.0.0/0
254 66882 ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate DNAT
0 0 OVPN all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 9197 packets, 9899K bytes)
pkts bytes target prot opt in out source destination
Chain ACCESS_RESTRICTION (0 references)
pkts bytes target prot opt in out source destination
Chain DNSFILTER_DOT (0 references)
pkts bytes target prot opt in out source destination
Chain FUPNP (0 references)
pkts bytes target prot opt in out source destination
Chain INPUT_ICMP (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
0 0 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 13
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
Chain INPUT_PING (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP icmp -- eth0 * 0.0.0.0/0 0.0.0.0/0
Chain NSFW (1 references)
pkts bytes target prot opt in out source destination
Chain OVPN (2 references)
pkts bytes target prot opt in out source destination
Chain PControls (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain PTCSRVLAN (1 references)
pkts bytes target prot opt in out source destination
Chain PTCSRVWAN (1 references)
pkts bytes target prot opt in out source destination
Chain SECURITY (0 references)
pkts bytes target prot opt in out source destination
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcpflags: 0x17/0x02 limit: avg 1/sec burst 5
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcpflags: 0x17/0x02
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcpflags: 0x17/0x04 limit: avg 1/sec burst 5
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcpflags: 0x17/0x04
0 0 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 limit: avg 1/sec burst 5
0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Chain default_block (0 references)
pkts bytes target prot opt in out source destination
Chain logaccept (0 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW LOG flags 7 level 4 prefix "ACCEPT "
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain logdrop (0 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW LOG flags 7 level 4 prefix "DROP "
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain other2wan (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- tun+ * 0.0.0.0/0 0.0.0.0/0
35 2873 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
admin@RT-AC68U-7BA8:/tmp/home/root#
Is Diversion using Pixelserv IP on br0: pixelserv-tls? Or just using 0.0.0.0 as blocking IP? I’m just about out of my league here, so don’t believe everything you read on the Internet.Here it is:
Appreciate the help...Code:admin@RT-AC68U-7BA8:/tmp/home/root# iptables -nvL Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 179 13288 ACCEPT udp -- br1 * 0.0.0.0/0 0.0.0.0/0 multiport dports 53,67 0 0 ACCEPT tcp -- br1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 639 52485 DROP all -- br1 * 0.0.0.0/0 0.0.0.0/0 state NEW 0 0 INPUT_PING icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 6001 675K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 149 11372 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 1323 370K PTCSRVWAN all -- !br0 * 0.0.0.0/0 0.0.0.0/0 2020 455K PTCSRVLAN all -- br0 * 0.0.0.0/0 0.0.0.0/0 2020 455K ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW 1176 340K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 state NEW 147 29685 OVPN all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW 4 1342 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68 0 0 INPUT_ICMP icmp -- * * 0.0.0.0/0 0.0.0.0/0 143 28343 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- br0 br1 0.0.0.0/0 0.0.0.0/0 state NEW 0 0 DROP all -- br1 br0 0.0.0.0/0 0.0.0.0/0 state NEW 305 72848 ACCEPT all -- br1 * 0.0.0.0/0 0.0.0.0/0 state NEW 40107 31M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 35 2873 other2wan all -- !br0 eth0 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- br0 br0 0.0.0.0/0 0.0.0.0/0 14 1344 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 254 66882 NSFW all -- * * 0.0.0.0/0 0.0.0.0/0 254 66882 ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate DNAT 0 0 OVPN all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 9197 packets, 9899K bytes) pkts bytes target prot opt in out source destination Chain ACCESS_RESTRICTION (0 references) pkts bytes target prot opt in out source destination Chain DNSFILTER_DOT (0 references) pkts bytes target prot opt in out source destination Chain FUPNP (0 references) pkts bytes target prot opt in out source destination Chain INPUT_ICMP (1 references) pkts bytes target prot opt in out source destination 0 0 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 0 0 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 13 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 Chain INPUT_PING (1 references) pkts bytes target prot opt in out source destination 0 0 DROP icmp -- eth0 * 0.0.0.0/0 0.0.0.0/0 Chain NSFW (1 references) pkts bytes target prot opt in out source destination Chain OVPN (2 references) pkts bytes target prot opt in out source destination Chain PControls (0 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain PTCSRVLAN (1 references) pkts bytes target prot opt in out source destination Chain PTCSRVWAN (1 references) pkts bytes target prot opt in out source destination Chain SECURITY (0 references) pkts bytes target prot opt in out source destination 0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcpflags: 0x17/0x02 limit: avg 1/sec burst 5 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcpflags: 0x17/0x02 0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcpflags: 0x17/0x04 limit: avg 1/sec burst 5 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcpflags: 0x17/0x04 0 0 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 limit: avg 1/sec burst 5 0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 Chain default_block (0 references) pkts bytes target prot opt in out source destination Chain logaccept (0 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW LOG flags 7 level 4 prefix "ACCEPT " 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain logdrop (0 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW LOG flags 7 level 4 prefix "DROP " 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain other2wan (1 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- tun+ * 0.0.0.0/0 0.0.0.0/0 35 2873 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 admin@RT-AC68U-7BA8:/tmp/home/root#
Yes, I'm using pixelserv and I think it's on br0, since its IP is 192.168.1.2 (main router DHCP addresses)Is Diversion using Pixelserv IP on br0: pixelserv-tls? Or just using 0.0.0.0 as blocking IP? I’m just about out of my league here, so don’t believe everything you read on the Internet.
If you enable logging in Diversion, do you see traffic logged from your br1 clients?
May 27 14:36:58 dnsmasq-dhcp[1159]: DHCPDISCOVER(br1) c2:96:da:80:d1:60
May 27 14:36:58 dnsmasq-dhcp[1159]: DHCPOFFER(br1) 192.168.20.112 c2:96:da:80:d1:60
May 27 14:36:58 dnsmasq-dhcp[1159]: DHCPREQUEST(br1) 192.168.20.112 c2:96:da:80:d1:60
May 27 14:36:58 dnsmasq-dhcp[1159]: DHCPACK(br1) 192.168.20.112 c2:96:da:80:d1:60
and
May 27 14:32:38 dnsmasq[1159]: query[A] www.ups.com from 192.168.1.126
May 27 14:32:38 dnsmasq[1159]: cached www.ups.com is <CNAME>
May 27 14:32:38 dnsmasq[1159]: cached ev.ups.com.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: cached ev1.ups.com.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: cached ev2b.ups.com.edgekey.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: cached ev2b.ups.com.edgekey.net.globalredir.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: forwarded www.ups.com to 8.8.8.8
May 27 14:32:38 dnsmasq[1159]: reply clients3.google.com is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply clients.l.google.com is 216.58.217.46
May 27 14:32:38 dnsmasq[1159]: reply www.ups.com is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply ev.ups.com.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply ev1.ups.com.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply ev2b.ups.com.edgekey.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply ev2b.ups.com.edgekey.net.globalredir.akadns.net is <CNAME>
May 27 14:32:38 dnsmasq[1159]: reply e13626.a.akamaiedge.net is 23.45.229.189
Enter device IP to filter by [q=Quit] 192.168.20.112
✖ 192.168.20.112 is not a router address
If you disable Pixerlserv in ep in Diversion, you can avoid accessing the 192.168.1.2 from br1, but I'm still not clear if your dns requests are getting through since you only showed a log of a br0 client.Yes, I'm using pixelserv and I think it's on br0, since its IP is 192.168.1.2 (main router DHCP addresses)
I do see the traffic from devices on br1, e.g.
Code:May 27 14:36:58 dnsmasq-dhcp[1159]: DHCPDISCOVER(br1) c2:96:da:80:d1:60 May 27 14:36:58 dnsmasq-dhcp[1159]: DHCPOFFER(br1) 192.168.20.112 c2:96:da:80:d1:60 May 27 14:36:58 dnsmasq-dhcp[1159]: DHCPREQUEST(br1) 192.168.20.112 c2:96:da:80:d1:60 May 27 14:36:58 dnsmasq-dhcp[1159]: DHCPACK(br1) 192.168.20.112 c2:96:da:80:d1:60 and May 27 14:32:38 dnsmasq[1159]: query[A] www.ups.com from 192.168.1.126 May 27 14:32:38 dnsmasq[1159]: cached www.ups.com is <CNAME> May 27 14:32:38 dnsmasq[1159]: cached ev.ups.com.akadns.net is <CNAME> May 27 14:32:38 dnsmasq[1159]: cached ev1.ups.com.akadns.net is <CNAME> May 27 14:32:38 dnsmasq[1159]: cached ev2b.ups.com.edgekey.net is <CNAME> May 27 14:32:38 dnsmasq[1159]: cached ev2b.ups.com.edgekey.net.globalredir.akadns.net is <CNAME> May 27 14:32:38 dnsmasq[1159]: forwarded www.ups.com to 8.8.8.8 May 27 14:32:38 dnsmasq[1159]: reply clients3.google.com is <CNAME> May 27 14:32:38 dnsmasq[1159]: reply clients.l.google.com is 216.58.217.46 May 27 14:32:38 dnsmasq[1159]: reply www.ups.com is <CNAME> May 27 14:32:38 dnsmasq[1159]: reply ev.ups.com.akadns.net is <CNAME> May 27 14:32:38 dnsmasq[1159]: reply ev1.ups.com.akadns.net is <CNAME> May 27 14:32:38 dnsmasq[1159]: reply ev2b.ups.com.edgekey.net is <CNAME> May 27 14:32:38 dnsmasq[1159]: reply ev2b.ups.com.edgekey.net.globalredir.akadns.net is <CNAME> May 27 14:32:38 dnsmasq[1159]: reply e13626.a.akamaiedge.net is 23.45.229.189
The weird thing is that if I use the "follow dnsmasq" feature in diversions, and I try to filter by the br1 IP addresses (192.168.20.x), I get
because Deviation doesn't know about my alternate DHCP on br1Code:Enter device IP to filter by [q=Quit] 192.168.20.112 ✖ 192.168.20.112 is not a router address
At this point I'm positive that my problems are caused by a weird interaction between Diversion and vlans (to be clear: I'm not blaming Diversion, I'm sure I'm doing something that was not designed for). If I disable Diversion, all problems disappear. With Diversion enabled, some things work just fine (e.g. Outlook email and the speedtest app in my Android phone, all my media devices streaming, etc) but other, like a simple browsing of the ups.com page from Chrome in Android takes forever to refresh or sometimes doesn't even load (even if I can see the event in the dnsmasq.log, as per above. 192.168.20.112 is my Android phone and I see a lot of activity from it, both the one that works like Outlook and the one that doesn't like Chrome)
So I'm sure you are onto something with your question...
I will try disabling pixelserv tomorrow.
# Allow BR1 to access WAN
iptables -D FORWARD -i br1 -m state --state NEW -j ACCEPT >/dev/null 2>&1
iptables -I FORWARD -i br1 -m state --state NEW -j ACCEPT
# Prevent BR1 from accessing BR0 and vice versa
iptables -D FORWARD -i br1 -o br0 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP
iptables -D FORWARD -i br0 -o br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br0 -o br1 -m state --state NEW -j DROP
#
iptables -D INPUT -i br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I INPUT -i br1 -m state --state NEW -j DROP
# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p tcp --dport 53 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p tcp --dport 53 -j ACCEPT
# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT
See if something simple works only in the INPUT chain:I'm pretty sure I would need a FORWARD-ACCEPT rule from br1 to br0 with source anywhere and destination 192.168.1.2 that executes before the FORWARD-DROP rule blocking all br1 to br0 traffic, but I have no idea if I also need something in the INPUT chain
iptables -I INPUT -i br1 -d 192.168.1.2/32 -p tcp -m multiport --dport 80,443 -j ACCEPT
Thanks for doing my homework!See if something simple works only in the INPUT chain:
Code:iptables -I INPUT -i br1 -d 192.168.1.2/32 -p tcp -m multiport --dport 80,443 -j ACCEPT
iptables -I FORWARD -i br1 -d 192.168.1.2/32 -p tcp -m multiport --dport 80,443 -j ACCEPT
Same experience here. Ended up disabling it and going back to uBlock Origin.I think we can safely say that YouTube ad blocking does not really work (impossible to do?). I've had the feature on for weeks, and I keep seeing video ads and repeats of the same video ads over and over again. I'm not a coder, so I'm not coming at this from that angle (i.e. I'm not criticizing or complaining), but just stating a bald fact from the end-user position.
On the other hand, Diversion's ad blocking is a true wonder!
Anton
I highly recommend you looking at whitelisted domains from links for this github,
https://raw.githubusercontent.com/anudeepND/whitelist/master/domains/referral-sites.txt
https://raw.githubusercontent.com/anudeepND/whitelist/master/domains/whitelist.txt
and adding them with
nano /opt/share/diversion/list/whitelist*
copy and paste
run diversion el options for whitelist sort and verify, then process.
the whitelist above usually fixes things that get broken from ad-blockers.
It's not 100% effective but it eliminates many annoying ads. I can live with it.I think we can safely say that YouTube ad blocking does not really work (impossible to do?). I've had the feature on for weeks, and I keep seeing video ads and repeats of the same video ads over and over again. I'm not a coder, so I'm not coming at this from that angle (i.e. I'm not criticizing or complaining), but just stating a bald fact from the end-user position.
On the other hand, Diversion's ad blocking is a true wonder!
Anton
It seems to break YouTube for me a lot.It's not 100% effective but it eliminates many annoying ads. I can live with it.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!