What's new

Asus AC68-u iptable rule question

  • 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!

One possible "advantage" of using DNSFilter is that it also blocks DoT traffic. The assumption being that the client will fall back to traditional DNS. But that could also be added to the custom script if required.
So DNSFilter can capture DOT traffic??
 
I haven't had a chance to change it yet. Though, now I am wondering whether to just delete the rule and run with DNSFilter as the others in the thread have mentioned..
Hey it is your choice. I imagine the others method is the best course of action. If you feel such course is correct, go for it. I hope it works. Let us know what works and what doesn't. That after all is what helps other users. Not who is right and wrong.
 
Hey it is your choice. I imagine the others method is the best course of action. If you feel such course is correct, go for it. I hope it works. Let us know what works and what doesn't. That after all is what helps other users. Not who is right and wrong.
Yeah, also now deciding whether to ditch the ac68u and look at going for a Ubiquti dream machine and get into the UniFi side and start tinkering with the network and learning more about networking in general.
 
Probably is my weakest area in terms on knowlege. Going down the Pihole rabbit hole and wanting to learn more about networking I feel it's a very capable device. Will probably keep an eye out for when one goes on sale.
There is nothing wrong with the path you have taken. I can break down for you why I specified my rules if you would like.
 
Code:
iptables -D PREROUTING -t nat ! -s 192.168.1.20/32 ! -d 192.168.1.20/32 -i br0 -p tcp -m tcp --dport 53 -j DNAT --to-destination 192.168.1.20 2>/dev/null
iptables -D PREROUTING -t nat ! -s 192.168.1.20/32 ! -d 192.168.1.20/32 -i br0 -p udp -m udp --dport 53 -j DNAT --to-destination 192.168.1.20 2>/dev/null
iptables -D PREROUTING -t nat -i br0 -p tcp -m tcp --dport 53 -m mac --mac-source XX:XX:XX:XX:XX:XX  -j RETURN 2>/dev/null
iptables -D PREROUTING -t nat -i br0 -p udp -m udp --dport 53 -m mac --mac-source XX:XX:XX:XX:XX:XX  -j RETURN 2>/dev/null
iptables -D PREROUTING -t nat -i br0 -p tcp -m tcp --dport 53 -m mac --mac-source YY:YY:YY:YY:YY:YY  -j RETURN 2>/dev/null
iptables -D PREROUTING -t nat -i br0 -p udp -m udp --dport 53 -m mac --mac-source YY:YY:YY:YY:YY:YY  -j RETURN 2>/dev/null
iptables -I PREROUTING -t nat ! -s 192.168.1.20/32 ! -d 192.168.1.20/32 -i br0 -p tcp -m tcp --dport 53 -j DNAT --to-destination 192.168.1.20 #### this considers any client pointed (or not) at your high availability IP - 192.168.1.20 while excluding its own traffic
iptables -I PREROUTING -t nat ! -s 192.168.1.20/32 ! -d 192.168.1.20/32 -i br0 -p udp -m udp --dport 53 -j DNAT --to-destination 192.168.1.20 #### this considers any client pointed (or not) at your high availability IP - 192.168.1.20 while excluding its own traffic
iptables -I PREROUTING -t nat -i br0 -p tcp -m tcp --dport 53 -m mac --mac-source XX:XX:XX:XX:XX:XX  -j RETURN #### these rules take into consideration the traffic of the pihole devices so they do not get mangled with other 53 traffic.
iptables -I PREROUTING -t nat -i br0 -p udp -m udp --dport 53 -m mac --mac-source XX:XX:XX:XX:XX:XX  -j RETURN #### these rules take into consideration the traffic of the pihole devices so they do not get mangled with other 53 traffic.
iptables -I PREROUTING -t nat -i br0 -p tcp -m tcp --dport 53 -m mac --mac-source YY:YY:YY:YY:YY:YY  -j RETURN #### these rules take into consideration the traffic of the pihole devices so they do not get mangled with other 53 traffic.
iptables -I PREROUTING -t nat -i br0 -p udp -m udp --dport 53 -m mac --mac-source YY:YY:YY:YY:YY:YY  -j RETURN #### these rules take into consideration the traffic of the pihole devices so they do not get mangled with other 53 traffic.


DNSfilter will do this part below:

Code:
iptables -I PREROUTING -t nat -i br0 -p tcp -m tcp --dport 53 -m mac --mac-source XX:XX:XX:XX:XX:XX  -j RETURN #### these rules take into consideration the traffic of the pihole devices so they do not get mangled with other 53 traffic.
iptables -I PREROUTING -t nat -i br0 -p udp -m udp --dport 53 -m mac --mac-source XX:XX:XX:XX:XX:XX  -j RETURN #### these rules take into consideration the traffic of the pihole devices so they do not get mangled with other 53 traffic.
iptables -I PREROUTING -t nat -i br0 -p tcp -m tcp --dport 53 -m mac --mac-source YY:YY:YY:YY:YY:YY  -j RETURN #### these rules take into consideration the traffic of the pihole devices so they do not get mangled with other 53 traffic.
iptables -I PREROUTING -t nat -i br0 -p udp -m udp --dport 53 -m mac --mac-source YY:YY:YY:YY:YY:YY  -j RETURN #### these rules take into consideration the traffic of the pihole devices so they do not get mangled with other 53 traffic.

when you specifiy clients to nofilter option (a.k.a. you would need to specify no-filter for each pihole client).

However DNSFilter will not do this on the final chain

Code:
iptables -I PREROUTING -t nat ! -s 192.168.1.20/32 ! -d 192.168.1.20/32 -i br0 -p tcp -m tcp --dport 53 -j DNAT --to-destination 192.168.1.20 #### this considers any client pointed (or not) at your high availability IP - 192.168.1.20 while excluding its own traffic
iptables -I PREROUTING -t nat ! -s 192.168.1.20/32 ! -d 192.168.1.20/32 -i br0 -p udp -m udp --dport 53 -j DNAT --to-destination 192.168.1.20 #### this considers any client pointed (or not) at your high availability IP - 192.168.1.20 while excluding its own traffic

which means your high availability IP - 192.168.1.20 will mangle its own traffic on itself when you choose to DNAT globally to it, unless you can also make a no-filter exclusion to it as well.
 
Last edited:
Would just have been nice if they made their newer UDR WiFi6 machine with a stronger cpu.
I agree completely. The sad part is WiFi6 will probably take a good few years to truely get good. I imagine there are undiscovered vulnerabilities. (as there will always be), and unperceived performance issues.
 
Would just have been nice if they made their newer UDR WiFi6 machine with a stronger cpu.
@josh3003 if you choose to continue down your current path, you can use DNSFilter if you like, but it has some exceptions to consider. please review this post:

It will explain any exceptions you must consider. I took the time to add comments , and provide commentary on using DNSFilter if you choose that route. Something the other users failed to provide. cough cough... yes it is easy say, go use dnsfilter, but it would be nice to provide more details on doing such.
 
It blocks it, yes.
Here is my expressed concern with using DNSFilter. The way it is designed is to mainly consider "externel" DNS sources. Users have tried to adapt it for local configurations.

Okay, locally we specify pihole 1, and pihole 2 to nofilter exclusion. Okay that is good, what does our rule look like for our virtual highavailability server? have we made an exclusion for it before we decide to point our clients to use it globally? That is how I came up with my rule chain. However, does DNSfilter prescribe this same logic? I mean @RMerlin does a nice job with DNSFilter, but before we start telling users to just turn to using it for all DNS redirection concerns, we should really pick apart their specific use case and see if it will actually handle their use.
 
Last edited:
I agree completely. The sad part is WiFi6 will probably take a good few years to truely get good. I imagine there are undiscovered vulnerabilities. (as there will always be), and unperceived performance issues.
Is it a worthwhile investment to replace this ac68u? They both use AC wifi but afaik the ac68u is nearing ~10+ years old. I think it's a bad idea to get the UDR for the cpu hit and just go with the UDM for the all in one functionality. The AC68u has plrenty of range throughout the house so it works fine for my needs. Just wondering if it'll give me better throughput for gigabit internet speeds.
 
Is it a worthwhile investment to replace this ac68u? They both use AC wifi but afaik the ac68u is nearing ~10+ years old. I think it's a bad idea to get the UDR for the cpu hit and just go with the UDM for the all in one functionality. The AC68u has plrenty of range throughout the house so it works fine for my needs. Just wondering if it'll give me better throughput for gigabit internet speeds.
It would work if you are not concerned with bufferbloat and QoS at those speed. If you are looking to set it up and forget it, then you should be fine. If you want to adapt and learn as technology changes, maybe you should consider a different platform to do such.
 
It would work if you are not concerned with bufferbloat and QoS at those speed. If you are looking to set it up and forget it, then you should be fine. If you want to adapt and learn as technology changes, maybe you should consider a different platform to do such.
I don't have QoS enabled because NaT hw acceleration becomes disabled and the speed tanks. Isn't bufferbloat tied to QoS?
 
I don't have QoS enabled because NaT hw acceleration becomes disabled and the speed tanks. Isn't bufferbloat tied to QoS?
Bufferbloat is tied to your ISP connection (specifically how it responds to all your various network connections). That is the main reason to consider it. Most people in the "router" world say speeds above 300 on consumer grade routers should skip QoS considerations (these routers generally use mips or ARM based architectures), but with newer x86/64 configurations, QoS mods have been showing some promising network improvements.
 
Bufferbloat is tied to your ISP connection (specifically how it responds to all your various network connections). That is the main reason to consider it. Most people in the "router" world say speeds above 300 on consumer grade routers should skip QoS considerations (these routers generally use mips or ARM based architectures), but with newer x86/64 configurations, QoS mods have been showing some promising network improvements.
Interesting! Well I'll probably be going between 250Mbps, 400Mbps and 1000Mbps connections depending on month to month. So is there recommendations on routers to look out for that will improve over the ac68u?
 
Interesting! Well I'll probably be going between 250Mbps, 400Mbps and 1000Mbps connections depending on month to month. So is there recommendations on routers to look out for that will improve over the ac68u?
well the x86/64 configurations are usually configurations people have self built or third party companies that do such, typically not your big box routers. Even then you really are on a journey on your own. You won't have the great support provided here like you do with asus products.
 
Ok great,
Is it possible to have another IP address in there or does it break how the traffic is redirected? As I mentioned I have a cloud based pihole as well. Otherwise is this better to use than dnsfilter?
You would have to create balance rules, and mark/mask matching rules in the mangle rules as well as the IP Rules for this, honestly quite a bit.
 

Similar threads

Latest threads

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!

Members online

Top