Diversion Seeing Ads (Mobile/Tablets)

[chongnt]

It actually blocks the character 65, so it also blocks dns queries with a total length of 65 lol.
It seems better to create custom firmware using the source below.

GitHub - rozahp/dnsmasq: This repo has moved to https://github.com/rozahp/dnsmasq-patch

This repo has moved to https://github.com/rozahp/dnsmasq-patch - rozahp/dnsmasq

github.com

Like others I found a few normal query blocked due to this as well. I tested by manually adding the public ip and and blocked domain in diversion blacklist. Then I run "service restart_dnsmasq". Now these domains can be resolved temporarily from the 'blacklist'. A reboot will make all domain in the list into blocked ip though.
How do I add new addn-hosts in /tmp/etc/dnsmasq.conf? I am not sure if this is worth the effort. For some the list may grow too long to maintain. Or is there any other workaround?

Edit: I managed to add it in dnsmasq.add. But it is not working actually. It might be cache or I mistakenly removed the iptables when I tested it.

Update: Looking at the packet, DNS query type 65 is highlight in blue "00 41". It has "00" in front and follow by query Class Internet which has a hex value of "00 01". I extend the iptables hex string from "|000041|" to "|0000410001|". So it has to be more specific match to get rejected by iptables. The few sites that were not loading before are working now.

Below is a sample of type A DNS query which happens to have an ip lengh of 65 (0x0041 in hex) that matches the iptables reject rule. Original rules only matches 6 hex digits (000041). As a result, this non type 65 query packet gets dropped.
With the new hex string in the iptables reject rule of "0000410001", it has to match 10 hex digits. Meaning this includes length and identification id. In this sample, the hex is "0000410e96" which does not match "
0000410001" and will not be rejected by the rule.

Edited to obsfucate router mac address.

 

[Background]

Like others I found a few normal query blocked due to this as well. I tested by manually adding the public ip and and blocked domain in diversion blacklist. Then I run "service restart_dnsmasq". Now these domains can be resolved temporarily from the 'blacklist'. A reboot will make all domain in the list into blocked ip though.
How do I add new addn-hosts in /tmp/etc/dnsmasq.conf? I am not sure if this is worth the effort. For some the list may grow too long to maintain. Or is there any other workaround?

Edit: I managed to add it in dnsmasq.add. But it is not working actually. It might be cache or I mistakenly removed the iptables when I tested it.

Update: Looking at the packet, DNS query type 65 is highlight in blue "00 41". It has "00" in front and follow by query Class Internet which has a hex value of "00 01". I extend the iptables hex string from "|000041|" to "|0000410001|". So it has to be more specific match to get rejected by iptables. The few sites that were not loading before are working now.
View attachment 34800

Below is a sample of type A DNS query which happens to have an ip lengh of 65 (0x0041 in hex) that matches the iptables reject rule. Original rules only matches 6 hex digits (000041). As a result, this non type 65 query packet gets dropped.
With the new hex string in the iptables reject rule of "0000410001", it has to match 10 hex digits. Meaning this includes length and identification id. In this sample, the hex is "0000410e96" which does not match "
0000410001" and will not be rejected by the rule.
View attachment 34801
Edited to obsfucate router mac address.

How you finding the updated block?

 

[chongnt]

How you finding the updated block?

I have been using the updated block for over a week now and for my usage I did not find any abnormality. Nothing seems to be broken. Here is the updated block I am using.

iptables -I INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m comment --comment "DNS Type 65" -m string --hex-string "|0000410001|" --algo bm -j REJECT
iptables -I FORWARD -p udp --dport 53 -m comment --comment "DNS Type 65" -m string --hex-string "|0000410001|" --algo bm -j REJECT

To remove the block,

iptables -D INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m comment --comment "DNS Type 65" -m string --hex-string "|0000410001|" --algo bm -j REJECT
iptables -D FORWARD -p udp --dport 53 -m comment --comment "DNS Type 65" -m string --hex-string "|0000410001|" --algo bm -j REJECT

 

[Treadler]

FYI, the Cloudflare Family/Gateway product blocks type 65 queries since February.

Apple with iOS 14 pokes a hole in DNS filtering with query type 65

@NordicMember This link has since expired. Are you able to upload it again? Cheers!

community.cloudflare.com

Perhaps Diversion should, also?

Looks like Adguard are onto it as well?

Make sure AdGuard Home blocks TYPE65 queries for domains that are blocked · Issue #2135 · AdguardTeam/AdGuardHome

When domain is blocked, we should prevent all kinds of DNS queries. @szolin could you please double-check that we do this in AGH (and in AG DNS as well)?

github.com

 

[Background]

I have been using the updated block for over a week now and for my usage I did not find any abnormality. Nothing seems to be broken. Here is the updated block I am using.

iptables -I INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m comment --comment "DNS Type 65" -m string --hex-string "|0000410001|" --algo bm -j REJECT
iptables -I FORWARD -p udp --dport 53 -m comment --comment "DNS Type 65" -m string --hex-string "|0000410001|" --algo bm -j REJECT

To remove the block,

iptables -D INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m comment --comment "DNS Type 65" -m string --hex-string "|0000410001|" --algo bm -j REJECT
iptables -D FORWARD -p udp --dport 53 -m comment --comment "DNS Type 65" -m string --hex-string "|0000410001|" --algo bm -j REJECT

Hi, I tried that code but I seem to get `iptables: No chain/target/match by that name.`

 

[chongnt]

Hi, I tried that code but I seem to get `iptables: No chain/target/match by that name.`

Maybe can try without comment. The original one is without comment too.

To block:

iptables -I INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|0000410001|" --algo bm -j REJECT
iptables -I FORWARD -p udp --dport 53 -m string --hex-string "|0000410001|" --algo bm -j REJECT

In case something break or want to remove the block:

iptables -D INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|0000410001|" --algo bm -j REJECT
iptables -D FORWARD -p udp --dport 53 -m string --hex-string "|0000410001|" --algo bm -j REJECT

 

[Background]

Maybe can try without comment. The original one is without comment too.

#Enable block DNS query type 65
iptables -I INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|0000410001|" --algo bm -j REJECT
iptables -I FORWARD -p udp --dport 53 -m string --hex-string "|0000410001|" --algo bm -j REJECT

#Disable block DNS query type 65
iptables -D INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|0000410001|" --algo bm -j REJECT
iptables -D FORWARD -p udp --dport 53 -m string --hex-string "|0000410001|" --algo bm -j REJECT

Thanks! That allowed me to enter the command no error but also same time no success message? Is that normal.

 

[chongnt]

Thanks! That allowed me to enter the command no error but also same time no success message? Is that normal.

Yes, it is normal. In order to add comment, seems like need to have

modprobe xt_comment

. I have this in init-start script. You can run this first before the one with comment. Anyway, it will work without comment.

iptables comment

I gather, on the RT-AC87U at least, that by running modprobe xt_comment I can add -m comment --comment "My comment" in an iptables rule. Is there somewhere I can check which models have this module?

www.snbforums.com

To verify the rule

iptables -nvL INPUT | grep 'pkts\|0000410001'
iptables -nvL FORWARD | grep 'pkts\|0000410001'

I don't have anything that hit the second rule. This is my output

admin@RT-AC86U-DBA8:/tmp/home/root# iptables -nvL INPUT | grep 'pkts\|0000410001'
 pkts bytes target     prot opt in     out     source               destination         
24054 1643K REJECT     udp  --  *      *       0.0.0.0/0            192.168.1.1          udp dpt:53 /* DNS Type 65 */ STRING match  "|0000410001|" ALGO name bm TO 65535 reject-with icmp-port-unreachable
admin@RT-AC86U-DBA8:/tmp/home/root# iptables -nvL FORWARD | grep 'pkts\|0000410001'
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 /* DNS Type 65 */ STRING match  "|0000410001|" ALGO name bm TO 65535 reject-with icmp-port-unreachable

 

[Background]

Yes, it is normal. In order to add comment, seems like need to have

modprobe xt_comment

. I have this in init-start script. You can run this first before the one with comment. Anyway, it will work without comment.

iptables comment

I gather, on the RT-AC87U at least, that by running modprobe xt_comment I can add -m comment --comment "My comment" in an iptables rule. Is there somewhere I can check which models have this module?

www.snbforums.com

To verify the rule

iptables -nvL INPUT | grep 'pkts\|0000410001'
iptables -nvL FORWARD | grep 'pkts\|0000410001'

I don't have anything that hit the second rule. This is my output

admin@RT-AC86U-DBA8:/tmp/home/root# iptables -nvL INPUT | grep 'pkts\|0000410001'
pkts bytes target     prot opt in     out     source               destination        
24054 1643K REJECT     udp  --  *      *       0.0.0.0/0            192.168.1.1          udp dpt:53 /* DNS Type 65 */ STRING match  "|0000410001|" ALGO name bm TO 65535 reject-with icmp-port-unreachable
admin@RT-AC86U-DBA8:/tmp/home/root# iptables -nvL FORWARD | grep 'pkts\|0000410001'
pkts bytes target     prot opt in     out     source               destination        
    0     0 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 /* DNS Type 65 */ STRING match  "|0000410001|" ALGO name bm TO 65535 reject-with icmp-port-unreachable

Thank you. That's brilliant.

Here is my result, looks pretty much the same (minus the comments).

ASUSWRT-Merlin RT-AC88U 386.3_beta2 Sat Jul 10 17:09:51 UTC 2021

RT-AC88U-E998:/tmp/home/root# iptables -nvL INPUT | grep 'pkts\|0000410001'
 pkts bytes target     prot opt in     out     source               destination                                                                                                                                                              
 3777  268K REJECT     udp  --  *      *       0.0.0.0/0            192.168.1.1                                                                                                 

RT-AC88U-E998:/tmp/home/root# iptables -nvL FORWARD | grep 'pkts\|0000410001'
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 STRING match  "|0000410001|" ALGO name bm TO 65535 reject-with icmp-port-unreachable

Still seeing ads/sponsored posts and such across iOS 14/iOS 15 Public Beta though?

 

[chongnt]

Thank you. That's brilliant.

Here is my result, looks pretty much the same (minus the comments).

ASUSWRT-Merlin RT-AC88U 386.3_beta2 Sat Jul 10 17:09:51 UTC 2021

RT-AC88U-E998:/tmp/home/root# iptables -nvL INPUT | grep 'pkts\|0000410001'
pkts bytes target     prot opt in     out     source               destination                                                                                                                                                            
3777  268K REJECT     udp  --  *      *       0.0.0.0/0            192.168.1.1                                                                                               

RT-AC88U-E998:/tmp/home/root# iptables -nvL FORWARD | grep 'pkts\|0000410001'
pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 STRING match  "|0000410001|" ALGO name bm TO 65535 reject-with icmp-port-unreachable

Still seeing ads/sponsored posts and such across iOS 14/iOS 15 Public Beta though?

I am sorry to hear that. Looking at the output, DNS query type 65 should be blocked now. It looks like the ads are not block by diversion, and not sneaking through DNS request type 65. I just relook into your first post, ads in application like Instagram and twitter could be difficult to block. It might be something like youtube ads. I tried Vellum apps, with diversion there is no ads shown. It does occasionally have an in-apps pop-up asking to purchase the apps. When I disconnect from wifi and use mobile data, there is ads on the bottom of the screen.

 

[Background]

I am sorry to hear that. Looking at the output, DNS query type 65 should be blocked now. It looks like the ads are not block by diversion, and not sneaking through DNS request type 65. I just relook into your first post, ads in application like Instagram and twitter could be difficult to block. It might be something like youtube ads. I tried Vellum apps, with diversion there is no ads shown. It does occasionally have an in-apps pop-up asking to purchase the apps. When I disconnect from wifi and use mobile data, there is ads on the bottom of the screen.

Hi, many thanks. Yeah the Vellum App seems to never get ads anymore since I updated the app via App Store so seems Diversion is blocking it again. On 4G there is an ad soon as you open the daily wallpaper/try to download.

Snapchat stories, Twitter and Instagram seem to be the worst ads, logs mention these are type=65

 

[chongnt]

Hi, many thanks. Yeah the Vellum App seems to never get ads anymore since I updated the app via App Store so seems Diversion is blocking it again. On 4G there is an ad soon as you open the daily wallpaper/try to download.

Snapchat stories, Twitter and Instagram seem to be the worst ads, logs mention these are type=65

I don't have the other apps so could not compare to my logs. Do you mean you still see query[type=65] in dnsmasq log? In your last output I see some packet count hits the reject rule, by right these should not reach dnsmasq anymore.

 

[CriticJay]

@chongnt 2 questions

1. Do the rejected type 65 packets show up in Diversion stats?

2. If the reject rule is entered correctly, would rejected packets show up in the dnsmasq log file? I view the log file through Diversion menu options and I don't believe I see them there.

 

[chongnt]

@chongnt 2 questions

1. Do the rejected type 65 packets show up in Diversion stats?

2. If the reject rule is entered correctly, would rejected packets show up in the dnsmasq log file? I view the log file through Diversion menu options and I don't believe I see them there.

Rejected packets will not show up in Diversion stats and dnsmasq log. You should see packet count in reject rule increases whenever a packet is rejected by the rule. If you don't see any of it in dnsmasq log and the counter in reject rule increases then it is working as expected.

 

[Background]

I don't have the other apps so could not compare to my logs. Do you mean you still see query[type=65] in dnsmasq log? In your last output I see some packet count hits the reject rule, by right these should not reach dnsmasq anymore.

Hi, yes when using the apps I'm seeing that type=65 in dnsmasq log. I noticed Skynet reporting this:

Is this anything to worry about? IPTables Rules Failed.

 

[chongnt]

Hi, yes when using the apps I'm seeing that type=65 in dnsmasq log. I noticed Skynet reporting this:


View attachment 35046

Is this anything to worry about? IPTables Rules Failed.

I have been adding and removing the two rules above many times and see no impact to Skynet. Was Skynet working before and did you make any changes to it? You can see Skynet iptables here

iptables -t raw -nvL

. Perhaps can try restart Skynet or reboot router and see if it helps.
It is strange that you still see query[type=65] in dnsmasq log after apply the rules. Do you see packet count increases when you run this command a few times?

iptables -nvL INPUT | grep 'pkts\|0000410001'

 

[Background]

I have been adding and removing the two rules above many times and see no impact to Skynet. Was Skynet working before and did you make any changes to it? You can see Skynet iptables here

iptables -t raw -nvL

. Perhaps can try restart Skynet or reboot router and see if it helps.
It is strange that you still see query[type=65] in dnsmasq log after apply the rules. Do you see packet count increases when you run this command a few times?

iptables -nvL INPUT | grep 'pkts\|0000410001'

Hi, running those commands:

@RT-AC88U-E998:/tmp/home/root# iptables -t raw -nvL
Chain PREROUTING (policy ACCEPT 23571 packets, 8151K bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
    0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
1630 68001 LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src LOG flags 7 level 4 prefix "[BLOCKED - INBOUND] "
1630 68001 DROP       all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src

Chain OUTPUT (policy ACCEPT 4982 packets, 1120K bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
@RT-AC88U-E998:/tmp/home/root# iptables -nvL INPUT | grep 'pkts\|0000410001'
pkts bytes target     prot opt in     out     source               destination
@RT-AC88U-E998:/tmp/home/root# iptables -nvL INPUT | grep 'pkts\|0000410001'
@RT-AC88U-E998:/tmp/home/root# iptables -t raw -nvL
Chain PREROUTING (policy ACCEPT 208K packets, 258M bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
    0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
1657 69109 LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src LOG flags 7 level 4 prefix "[BLOCKED - INBOUND] "
1657 69109 DROP       all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src

Chain OUTPUT (policy ACCEPT 122K packets, 56M bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
@RT-AC88U-E998:/tmp/home/root#

I can confirm another another reboot the query[type=65] in dnsmasq log has stopped.

20:16:30 dnsmasq[7964]: blocked by blockinglist app-analytics-v2.snapchat.com is 192.168.1.2
20:16:30 dnsmasq[7964]: reply us-central1-gcp.api.snapchat.com is <CNAME>
20:16:30 dnsmasq[7964]: reply us-central1-gcp.api.sc-gw.com is 35.190.43.134
20:16:30 dnsmasq[7964]: query[A] aws.api.snapchat.com from 192.168.1.50
20:16:30 dnsmasq[7964]: forwarded aws.api.snapchat.com to 1.1.1.2
20:16:30 dnsmasq[7964]: reply aws.api.snapchat.com is <CNAME>
20:16:30 dnsmasq[7964]: reply aws.api.sc-gw.com is <CNAME>
20:16:30 dnsmasq[7964]: reply eu-west1-aws.api.sc-gw.com is 63.32.165.80
20:16:30 dnsmasq[7964]: query[A] cf-st.sc-cdn.net from 192.168.1.50
20:16:30 dnsmasq[7964]: forwarded cf-st.sc-cdn.net to 1.1.1.2
20:16:30 dnsmasq[7964]: reply cf-st.sc-cdn.net is 99.86.116.41
20:16:30 dnsmasq[7964]: reply cf-st.sc-cdn.net is 99.86.116.29
20:16:30 dnsmasq[7964]: reply cf-st.sc-cdn.net is 99.86.116.72
20:16:30 dnsmasq[7964]: reply cf-st.sc-cdn.net is 99.86.116.75
20:16:31 dnsmasq[7964]: query[A] us-east4-gcp.api.snapchat.com from 192.168.1.50
20:16:31 dnsmasq[7964]: forwarded us-east4-gcp.api.snapchat.com to 1.1.1.2
20:16:31 dnsmasq[7964]: reply us-east4-gcp.api.snapchat.com is <CNAME>
20:16:31 dnsmasq[7964]: reply us-east4-gcp.api.sc-gw.com is 35.190.43.134
20:16:31 dnsmasq[7964]: query[A] gtq6.sct.sc-prod.net from 192.168.1.50
20:16:31 dnsmasq[7964]: forwarded gtq6.sct.sc-prod.net to 1.1.1.2
20:16:31 dnsmasq[7964]: reply gtq6.sct.sc-prod.net is 35.190.22.22
20:16:31 dnsmasq[7964]: query[A] bolt-gcdn.sc-cdn.net from 192.168.1.50
20:16:31 dnsmasq[7964]: forwarded bolt-gcdn.sc-cdn.net to 1.1.1.2
20:16:31 dnsmasq[7964]: reply bolt-gcdn.sc-cdn.net is 35.241.16.93
20:16:33 dnsmasq[7964]: query[AAAA] data.meethue.com from 192.168.1.65
20:16:33 dnsmasq[7964]: forwarded data.meethue.com to 1.1.1.2
20:16:33 dnsmasq[7964]: reply data.meethue.com is <CNAME>
20:16:33 dnsmasq[7964]: query[A] data.meethue.com from 192.168.1.65
20:16:33 dnsmasq[7964]: forwarded data.meethue.com to 1.1.1.2
20:16:33 dnsmasq[7964]: reply data.meethue.com is <CNAME>
20:16:33 dnsmasq[7964]: reply prod.huedatastore.com is 54.72.226.75
20:16:33 dnsmasq[7964]: reply prod.huedatastore.com is 54.195.131.198
20:16:34 dnsmasq[7964]: query[A] www.google.com from 192.168.1.85
20:16:34 dnsmasq[7964]: cached www.google.com is 142.250.179.228
20:16:34 dnsmasq[7964]: query[AAAA] www.google.com from 192.168.1.85
20:16:34 dnsmasq[7964]: cached www.google.com is 2a00:1450:4009:81d::2004
20:16:41 dnsmasq[7964]: query[A] europe-west1-gcp.api.snapchat.com from 192.168.1.50
20:16:41 dnsmasq[7964]: forwarded europe-west1-gcp.api.snapchat.com to 1.0.0.2
20:16:41 dnsmasq[7964]: forwarded europe-west1-gcp.api.snapchat.com to 1.1.1.2
20:16:41 dnsmasq[7964]: reply europe-west1-gcp.api.snapchat.com is <CNAME>
20:16:41 dnsmasq[7964]: reply europe-west1-gcp.api.sc-gw.com is 35.190.43.134
20:16:57 dnsmasq[7964]: query[A] configuration.apple.com from 192.168.1.131
20:16:57 dnsmasq[7964]: forwarded configuration.apple.com to 1.1.1.2
20:16:57 dnsmasq[7964]: reply configuration.apple.com is <CNAME>
20:16:57 dnsmasq[7964]: reply configuration.apple.com.akadns.net is <CNAME>
20:16:57 dnsmasq[7964]: reply configuration.apple.com.edgekey.net is <CNAME>
20:16:57 dnsmasq[7964]: reply e673.dsce9.akamaiedge.net is 2.16.75.200
20:17:01 dnsmasq[7964]: query[A] gcp.api.snapchat.com from 192.168.1.50
20:17:01 dnsmasq[7964]: forwarded gcp.api.snapchat.com to 1.1.1.2
20:17:01 dnsmasq[7964]: reply gcp.api.snapchat.com is <CNAME>
20:17:01 dnsmasq[7964]: reply gcp.api.sc-gw.com is 35.190.43.134
20:17:12 dnsmasq[7964]: query[A] clients3.google.com from 192.168.1.85
20:17:12 dnsmasq[7964]: forwarded clients3.google.com to 1.0.0.2
20:17:12 dnsmasq[7964]: forwarded clients3.google.com to 1.1.1.2
20:17:12 dnsmasq[7964]: reply clients3.google.com is <CNAME>

Example of Snapchat + ads (in between stories).



uiDivStats search for "snapchat"

2021-07-18 18:32    gcp.api.snapchat.com    XXX.XXX.X.XX    type=65    Allowed
2021-07-18 18:32    mvm.snapchat.com    XXX.XXX.X.XX  type=65    Allowed

I see a lot of this in uiDivStats too, I wonder if it's Apple Ads snapchat and other apps use in iOS 14/15?

2021-07-18 19:40    cf.iadsdk.apple.com    XXX.XXX.X.XX type=65    Allowed

 

[SomeWhereOverTheRainBow]

has any body tried

dns-rr=*,65,

 

[chongnt]

Hi, running those commands:

@RT-AC88U-E998:/tmp/home/root# iptables -t raw -nvL
Chain PREROUTING (policy ACCEPT 23571 packets, 8151K bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
    0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
1630 68001 LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src LOG flags 7 level 4 prefix "[BLOCKED - INBOUND] "
1630 68001 DROP       all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src

Chain OUTPUT (policy ACCEPT 4982 packets, 1120K bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
@RT-AC88U-E998:/tmp/home/root# iptables -nvL INPUT | grep 'pkts\|0000410001'
pkts bytes target     prot opt in     out     source               destination
@RT-AC88U-E998:/tmp/home/root# iptables -nvL INPUT | grep 'pkts\|0000410001'
@RT-AC88U-E998:/tmp/home/root# iptables -t raw -nvL
Chain PREROUTING (policy ACCEPT 208K packets, 258M bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
    0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
1657 69109 LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src LOG flags 7 level 4 prefix "[BLOCKED - INBOUND] "
1657 69109 DROP       all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src

Chain OUTPUT (policy ACCEPT 122K packets, 56M bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
@RT-AC88U-E998:/tmp/home/root#

I can confirm another another reboot the query[type=65] in dnsmasq log has stopped.

20:16:30 dnsmasq[7964]: blocked by blockinglist app-analytics-v2.snapchat.com is 192.168.1.2
20:16:30 dnsmasq[7964]: reply us-central1-gcp.api.snapchat.com is <CNAME>
20:16:30 dnsmasq[7964]: reply us-central1-gcp.api.sc-gw.com is 35.190.43.134
20:16:30 dnsmasq[7964]: query[A] aws.api.snapchat.com from 192.168.1.50
20:16:30 dnsmasq[7964]: forwarded aws.api.snapchat.com to 1.1.1.2
20:16:30 dnsmasq[7964]: reply aws.api.snapchat.com is <CNAME>
20:16:30 dnsmasq[7964]: reply aws.api.sc-gw.com is <CNAME>
20:16:30 dnsmasq[7964]: reply eu-west1-aws.api.sc-gw.com is 63.32.165.80
20:16:30 dnsmasq[7964]: query[A] cf-st.sc-cdn.net from 192.168.1.50
20:16:30 dnsmasq[7964]: forwarded cf-st.sc-cdn.net to 1.1.1.2
20:16:30 dnsmasq[7964]: reply cf-st.sc-cdn.net is 99.86.116.41
20:16:30 dnsmasq[7964]: reply cf-st.sc-cdn.net is 99.86.116.29
20:16:30 dnsmasq[7964]: reply cf-st.sc-cdn.net is 99.86.116.72
20:16:30 dnsmasq[7964]: reply cf-st.sc-cdn.net is 99.86.116.75
20:16:31 dnsmasq[7964]: query[A] us-east4-gcp.api.snapchat.com from 192.168.1.50
20:16:31 dnsmasq[7964]: forwarded us-east4-gcp.api.snapchat.com to 1.1.1.2
20:16:31 dnsmasq[7964]: reply us-east4-gcp.api.snapchat.com is <CNAME>
20:16:31 dnsmasq[7964]: reply us-east4-gcp.api.sc-gw.com is 35.190.43.134
20:16:31 dnsmasq[7964]: query[A] gtq6.sct.sc-prod.net from 192.168.1.50
20:16:31 dnsmasq[7964]: forwarded gtq6.sct.sc-prod.net to 1.1.1.2
20:16:31 dnsmasq[7964]: reply gtq6.sct.sc-prod.net is 35.190.22.22
20:16:31 dnsmasq[7964]: query[A] bolt-gcdn.sc-cdn.net from 192.168.1.50
20:16:31 dnsmasq[7964]: forwarded bolt-gcdn.sc-cdn.net to 1.1.1.2
20:16:31 dnsmasq[7964]: reply bolt-gcdn.sc-cdn.net is 35.241.16.93
20:16:33 dnsmasq[7964]: query[AAAA] data.meethue.com from 192.168.1.65
20:16:33 dnsmasq[7964]: forwarded data.meethue.com to 1.1.1.2
20:16:33 dnsmasq[7964]: reply data.meethue.com is <CNAME>
20:16:33 dnsmasq[7964]: query[A] data.meethue.com from 192.168.1.65
20:16:33 dnsmasq[7964]: forwarded data.meethue.com to 1.1.1.2
20:16:33 dnsmasq[7964]: reply data.meethue.com is <CNAME>
20:16:33 dnsmasq[7964]: reply prod.huedatastore.com is 54.72.226.75
20:16:33 dnsmasq[7964]: reply prod.huedatastore.com is 54.195.131.198
20:16:34 dnsmasq[7964]: query[A] www.google.com from 192.168.1.85
20:16:34 dnsmasq[7964]: cached www.google.com is 142.250.179.228
20:16:34 dnsmasq[7964]: query[AAAA] www.google.com from 192.168.1.85
20:16:34 dnsmasq[7964]: cached www.google.com is 2a00:1450:4009:81d::2004
20:16:41 dnsmasq[7964]: query[A] europe-west1-gcp.api.snapchat.com from 192.168.1.50
20:16:41 dnsmasq[7964]: forwarded europe-west1-gcp.api.snapchat.com to 1.0.0.2
20:16:41 dnsmasq[7964]: forwarded europe-west1-gcp.api.snapchat.com to 1.1.1.2
20:16:41 dnsmasq[7964]: reply europe-west1-gcp.api.snapchat.com is <CNAME>
20:16:41 dnsmasq[7964]: reply europe-west1-gcp.api.sc-gw.com is 35.190.43.134
20:16:57 dnsmasq[7964]: query[A] configuration.apple.com from 192.168.1.131
20:16:57 dnsmasq[7964]: forwarded configuration.apple.com to 1.1.1.2
20:16:57 dnsmasq[7964]: reply configuration.apple.com is <CNAME>
20:16:57 dnsmasq[7964]: reply configuration.apple.com.akadns.net is <CNAME>
20:16:57 dnsmasq[7964]: reply configuration.apple.com.edgekey.net is <CNAME>
20:16:57 dnsmasq[7964]: reply e673.dsce9.akamaiedge.net is 2.16.75.200
20:17:01 dnsmasq[7964]: query[A] gcp.api.snapchat.com from 192.168.1.50
20:17:01 dnsmasq[7964]: forwarded gcp.api.snapchat.com to 1.1.1.2
20:17:01 dnsmasq[7964]: reply gcp.api.snapchat.com is <CNAME>
20:17:01 dnsmasq[7964]: reply gcp.api.sc-gw.com is 35.190.43.134
20:17:12 dnsmasq[7964]: query[A] clients3.google.com from 192.168.1.85
20:17:12 dnsmasq[7964]: forwarded clients3.google.com to 1.0.0.2
20:17:12 dnsmasq[7964]: forwarded clients3.google.com to 1.1.1.2
20:17:12 dnsmasq[7964]: reply clients3.google.com is <CNAME>

Example of Snapchat + ads (in between stories).



uiDivStats search for "snapchat"

2021-07-18 18:32    gcp.api.snapchat.com    XXX.XXX.X.XX    type=65    Allowed
2021-07-18 18:32    mvm.snapchat.com    XXX.XXX.X.XX  type=65    Allowed

I see a lot of this in uiDivStats too, I wonder if it's Apple Ads snapchat and other apps use in iOS 14/15?

2021-07-18 19:40    cf.iadsdk.apple.com    XXX.XXX.X.XX type=65    Allowed

From your output, there is no rule listed when you run

iptables -nvL INPUT | grep 'pkts\|0000410001'

It was probably removed/not applied during that time. Since you no longer see it in dnsmasq log, looks like it is working. The one in uiDivStats looks like historical records? It will get replaced with new records and there should be no more type=65.

 

[SomeWhereOverTheRainBow]

From your output, there is no rule listed when you run

iptables -nvL INPUT | grep 'pkts\|0000410001'

It was probably removed/not applied during that time. Since you no longer see it in dnsmasq log, looks like it is working. The one in uiDivStats looks like historical records? It will get replaced with new records and there should be no more type=65.

maybe a dnsmasq wildcard can be used for all type 65

such as

dns-rr=*,65,