What's new

Diversion Type 65 Blocking killing website loading of certain sites

  • 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 so then it appears to have worked. Type65 is disabled and the websites load. However this was the way it was before I ran those commands. As long as I had Type 65 disabled the websites worked.
So your websites should load with this rule, and your type65 queries should return a null value with the incorporation of this firewall rule.
 
But why do I need to do that? I don't need to do that when I have Type 65 blocking disabled. Meaning now I would need a white list for just type 65 blocking lol.
Because the whitelist is expressly there for those anomalies or false positives that we encounter on a periodic basis. It seems that type 65 is no different. I think that would be a safe first troubleshooting step.
 
However my question still stands.. Isn't something wrong with the fact that I have to run this command & that it only works properly if I keep Type 65 blocking disabled?
It wouldn't be inaccurate to assume that I couldn't exactly not say that it is or isn't almost partially wrong, on the contrary, I'm possibly more or less not definitely rejecting the idea that in no way with any amount of uncertainty that I undeniably do or do not know whether it is or isn't wrong, if that it indeed wasn't wrong in the first place. Even if it wasn't wrong, that'd mean I'd really would have to know whether it was or wasn't wrong from the onset. You know what I mean?
 
However my question still stands.. Isn't something wrong with the fact that I have to run this command & that it only works properly if I keep Type 65 blocking disabled?
It seems there might be a flaw with the option in diversion, meaning @thelonelycoder needs to investigate when he is not on the road. However, right now he is on the road. You may have to keep watching this thread for when he has had appropriate time to investigate. He may wind up having to modify his IP table rules to one's similar to what I gave you. In the mean time you should update this thread prefix to be a diversion concern since you are inquiring about a function that is incorporated with in it. It will make it easier for @thelonelycoder to follow up on this matter.
 
Last edited:
It wouldn't be inaccurate to assume that I couldn't exactly not say that it is or isn't almost partially wrong, on the contrary, I'm possibly more or less not definitely rejecting the idea that in no way with any amount of uncertainty that I undeniably do or do not know whether it is or isn't wrong, if that it indeed wasn't wrong in the first place. Even if it wasn't wrong, that'd mean I'd really would have to know whether it was or wasn't wrong from the onset. You know what I mean?
What lol. Look I’m just trying to say that something seems wrong if I have to run commands that are kinda technical.
 
What lol. Look I’m just trying to say that something seems wrong if I have to run commands that are kinda technical.
(c) Pinnochio, Shrek the Third Motion Picture - "paraphrased"

:p LOL
 
What lol. Look I’m just trying to say that something seems wrong if I have to run commands that are kinda technical.
Hey, for some people turning the router on is kinda technical. All we have is your concern and ways we might offer help. In this realm there is not always going to be an answer that fills in all the knowledge gaps, but the hope at the end of the day is that you will have peace of mind on this matter.
 
Hey, for some people turning the router on is kinda technical. All we have is your concern and ways we might offer help. In this realm there is not always going to be an answer that fills in all the knowledge gaps, but the hope at the end of the day is that you will have peace of mind on this matter.
No I’m very grateful for your help. Thanks. I just wanted to alert the forum to a possible problem with diversion.
 
No I’m very grateful for your help. Thanks. I just wanted to alert the forum to a possible problem with diversion.
If you wouldn't mind, could you edit the thread prefix label to be diversion, so that way it is actually on the thread title. It not only will notify the readers that it is associated with diversion, but also helps developers like @thelonelycoder prioritize the issue faster.
 
Yesterday I capture at the outgoing interface, so that explain why I could not see how it gets block. Now I capture at the wifi interface.

Let's see what is going on...
1. Type A query to microsoft.com is getting reply.
1663642351643.png


2. There are both HTTPS type 65 and Type A query to c.microsoft.com. With Type 65 blocked, there will be no response for HTTPS query which is normal. Here we see there is query response for Type A query. This query looks normal.
1663642766005.png


3. However, for the other DNS query, it only send type 65 query and since it is being blocked, it does not get resolves.
1663642859953.png


After remove type 65 blocking, we can see type 65 response.
1663643678695.png


Usually I see both HTTPS and Type A DNS query for the same domain. But for this particular domain there is only type 65 query.
In a way, type 65 blocking is working as expected.
 
So is there a way to remove those things from IPTables ? What would be the command to remove those edits? Since I can resolve the problem with just disabling type 65 in diversion settings I want to just keep things unmodified.
 
So is there a way to remove those things from IPTables ? What would be the command to remove those edits? Since I can resolve the problem with just disabling type 65 in diversion settings I want to just keep things unmodified.
Code:
#to-delete

##ipv4
iptables -D OUTPUT_DNS -m string --hex-string "|0000410001|" --algo bm --to 65535 --icase -j logdrop_dns
##ipv6
ip6tables -D OUTPUT_DNS -m string --hex-string "|0000410001|" --algo bm --to 65535 --icase -j logdrop_dns

#to-put-at-top-of-the-chain

##ipv4
iptables -I OUTPUT_DNS -m string --hex-string "|0000410001|" --algo bm --to 65535 --icase -j logdrop_dns
##ipv6
ip6tables -I OUTPUT_DNS -m string --hex-string "|0000410001|" --algo bm --to 65535 --icase -j logdrop_dns

#to-append-to-bottom-of-chain

##ipv4
iptables -A OUTPUT_DNS -m string --hex-string "|0000410001|" --algo bm --to 65535 --icase -j logdrop_dns
##ipv6
ip6tables -A OUTPUT_DNS -m string --hex-string "|0000410001|" --algo bm --to 65535 --icase -j logdrop_dns


use iptables-save to confirm they are at what position you want.
 
I try to replicate my very first scenario with mobile data connection from VPN to router. I was able to load the pages yesterday.
Capture at router vpn interface, there is actually both HTTPS and Type A query received. Even with type 65 blocked, type A query got the response and hence the page can load properly.

1663646419421.png


I got more questions.... With wifi connection, there is only type 65 query for this domain. Somehow with mobile internet over VPN to the router, the same iphone is sending Type A query along with type 65 query. Also, how can it work when the rule is apply in output chain? type 65 query should be blocked anyway.
 
I try to replicate my very first scenario with mobile data connection from VPN to router. I was able to load the pages yesterday.
Capture at router vpn interface, there is actually both HTTPS and Type A query received. Even with type 65 blocked, type A query got the response and hence the page can load properly.

View attachment 44310

I got more questions.... With wifi connection, there is only type 65 query for this domain. Somehow with mobile internet over VPN to the router, the same iphone is sending Type A query along with type 65 query. Also, how can it work when the rule is apply in output chain? type 65 query should be blocked anyway.
to be honest, a better way of dropping them may be to use a chain on the output "raw" tables as output, but I haven't really investigated that far. Been mainly looking at them on the filter table.

Code:
iptables -t raw -I OUTPUT -p udp --dport 53 -m comment --comment DNS_Type_65 -m string --hex-string "|0000410001|" --algo bm --to 65535 --icase -j DROP
iptables -t raw -I OUTPUT -p tcp --dport 53 -m comment --comment DNS_Type_65 -m string --hex-string "|0000410001|" --algo bm --to 65535 --icase -j DROP
 
Last edited:
Also, how can it work when the rule is apply in output chain? type 65 query should be blocked anyway.
Another way to think about it: a Type65 query can be allowed from the client, but a Type65 response should be blocked by blocking dnsmasq from forwarding the query upstream (in the OUTPUT chain).
 
I've been seeing similar issues with enabling Type65 blocking. Some websites hang and don't load. Turning off the blocking makes everything work properly again.
 

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