ComputerSteve
Senior Member
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.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.
Ok but did this fix the problem & what is the problem then.. Why can't I leave type 65 on in diversion?So your websites should load with this rule, and your type65 queries should return a null value with the incorporation of this firewall rule.
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.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.
I see the rule in that output list. So I guess it took the rule.That is normal. You would see no output if the rule worked.
What is the output of
iptables-save
If you see the rule in that output list, then it took the rule.
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?I see the rule in that output list. So I guess it took the rule.
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.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?
What lol. Look I’m just trying to say that something seems wrong if I have to run commands that are kinda technical.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?
(c) Pinnochio, Shrek the Third Motion Picture - "paraphrased"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.What lol. Look I’m just trying to say that something seems wrong if I have to run commands that are kinda technical.
No I’m very grateful for your help. Thanks. I just wanted to alert the forum to a possible problem with diversion.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.
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.No I’m very grateful for your help. Thanks. I just wanted to alert the forum to a possible problem with diversion.
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.
#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
iptables-save
to confirm they are at what position you want.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.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.
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
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).Also, how can it work when the rule is apply in output chain? type 65 query should be blocked anyway.
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!