Hello,
Wondering anyone from Asus here or anyone who could connect me to the developers there?
Using Asus RT-AC58U in Access Point(AP) mode and expect it to simply bridge wired with wireless but seems like it’s re-writing DNS packets source as well as the destination.
-
DNS port 53 traffic going out, the source is re-written with the management IP of the AP on the LAN. So virtually all DNS traffic hits the router from the (management) IP of the Asus AP instead of real clients.
-
If I define DNS as x.x.x.x on DHCP, the Asus AP picks that up and re-writes destination to x.x.x.x and hence even if any client uses y.y.y.y, the packets are simply re-written.
I see the rule in iptables on Asus AP. All these issues give an idea that someone created AP mode (besides regular routing mode) and missed to disable the DNS related NATing features in the AP mode. So far my discussions with their support have been going quite slow and would greatly appreciate if someone could connect me to right folks in there so they can release a firmware fix for it.
Thanks.
I’m curious to know why they would add such a thing, and how you got the iptables rules from the device. Do these Asus routers provide SSH directly into the shell?
Ryan
And if so, can you set up your own service to remove their iptables rule after it’s been added or otherwise counteract it.
At least temporarily, anyways.
-Neil
I’m curious to know why they would add such a thing,
No idea
and how you got the iptables rules from the device. Do these Asus routers provide SSH directly into the shell?
Yes, it does.
The input/output/forward chains are empty as one would expect but looking at PREROUTING:
anurag@RT-AC58U:/tmp/home/root# iptables -t nat -L PREROUTING -v -n
Chain PREROUTING (policy ACCEPT 751K packets, 133M bytes)
pkts bytes target prot opt in out source destination
361K 25M DNAT udp – * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 to:172.16.0.6:53
anurag@RT-AC58U:/tmp/home/root#
Note: 172.16.0.6 is the management IP of the Asus AP.
I tried deleting the rule and it drops the traffic completely. So DNS resolution stops working and I am unsure why. It’s not like default drop or anything. I can edit the rule and whatever active port 53 related rule is there works. But I want case of no such rule at all. 
I setup pihole on Intel NUC little while ago and all Pihole gets is 100% of wifi client traffic behind Asus wifi management IP. :-\
Plus no matter what DNS I put, queries goes via whatever router gave up when Asus booted up.
Here’s how creepy it gets:
On Rasberry Pi (which is not behind Asus AP but a different switch)
anurag@raspberrypi:~ $ dig whoami.akamai.com @1.1.1.1 a +short
whoami.akamai.net.
162.158.226.218
anurag@raspberrypi:~ $ dig whoami.akamai.com @8.8.8.8 a +short
whoami.akamai.net.
172.253.244.3
anurag@raspberrypi:~ $ dig whoami.akamai.com @9.9.9.9 a +short
whoami.akamai.net.
103.224.242.10
anurag@raspberrypi:~ $
All normal and good.
Now, from the device (which is behind Asus AP):
~> dig whoami.akamai.net @1.1.1.1 a +short
172.217.34.65
~> dig whoami.akamai.net @8.8.8.8 a +short
172.217.34.65
~> dig whoami.akamai.net @9.9.9.9 a +short
172.217.34.65
dig whoami.akamai.net @1.2.3.4 a +short
172.217.34.65
dig whoami.akamai.net @5.6.7.8 a +short
172.217.34.65
Essentially Asus picked 8.8.8.8 because I put that during the test and rebooted the AP. I will stick with 8.8.8.8 until DHCP lease expires and the new server is provided.
Have you tried disabling the ‘redirect when wan down’ feature? I’m guessing they hijack the dns to redirect the user to a captive portal “your internet is down” error page possibly?
No such feature when running in AP mode. AP mode gives options of wireless settings (SSID etc) and IP for management of the device.
I don't know about this case but I've occasionally noticed devices
where you have to put the device into the mode where the feature
config shows up in the UI in order to disable it. The feature itself
acts independent of whether it shows up in the UI.
Does the asus AP have an "nvram" command? That's likely where the
config is stored.
Regards,
Bill Herrin
Did you try to add
-t nat -A POSTROUTING -p tcp -m tcp --dport 53 -j ACCEPT
-t nat -A POSTROUTING -p udp -m udp --dport 53 -j ACCEPT
after the deletion?
Hi Alarig
I tried that but somehow DNS traffic still does not work. I tried adding rules in prerouting as well and still no impact.
anurag@RT-AC58U:/tmp/home/root# iptables -t nat -L PREROUTING -v -n
Chain PREROUTING (policy ACCEPT 25 packets, 3147 bytes)
pkts bytes target prot opt in out source destination
672 46143 ACCEPT udp – * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
anurag@RT-AC58U:/tmp/home/root# iptables -t nat -L -v -n
Chain PREROUTING (policy ACCEPT 63 packets, 10481 bytes)
pkts bytes target prot opt in out source destination
993 68310 ACCEPT udp – * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
Chain INPUT (policy ACCEPT 46 packets, 8909 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp – * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
anurag@RT-AC58U:/tmp/home/root#
dig @1.1.1.1 whoami.akamai.net
; <<>> DiG 9.10.6 <<>> @1.1.1.1 whoami.akamai.net
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
Whether or not I have these rules, I see no traffic on port 53 when doing tcpdump on the core router (in the North of Asus wifi AP). So clearly firewall rules are not working.
Please suggest if you see something wrong here.
Also, in meantime, I heard from Asus and their support mentioned that this re-writing is intentional and is done so that end users can access device on router.asus.com hostname. I requested them to make this feature optional so that at least folks like us can disable it. Let’s see how that goes.
Thanks.
Hello
An update on this issue:
Going through (long) Asus support channel, they first agreed that this was intentional to make router.asus.com work but did take my request to make that optional. They have issued me a test firmware which so far seems to be working perfectly with no-rewriting rules. Hoping that it doesn’t bring any side effects and they eventually put it in their public release after testing.
Thanks.
I had a similar discussion with another vendor recently while testing their mesh wireless systems. This vendor’s units are actually re-writing dhcp requests that clients make to point DNS to the primary mesh unit. This even happened when the mesh platform was in pure bridge mode (as opposed to router mode). The vendor said this was to make sure their app worked reliably. I’d say this sort of behaviour has quietly become common in the one app to rule it all world.
I experienced this as well dealing with some soho “routers” such as the RT-AC1200. I imagine this configuration is something in-common with a lot of their offerings. The issue was resolved by making sure the primary DHCP server and the Asus device both pointed to the same DNS server.
This is annoying behavior, because unless you are doing something weird with actually signing DNS or TCP DNS, the router can just inject a fake response for their one DNS name they need into any UDP DNS stream with a tiny bit of inspection. Hijacking all of DNS is the DUMB way to do it.
And either way you go, it should be configuration flaggable on/off.