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. 1. 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. 2. 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. -- Anurag Bhatia anuragbhatia.com
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 On Oct 28 2020, at 11:33 am, Anurag Bhatia <me@anuragbhatia.com> wrote:
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.
-- Anurag Bhatia
anuragbhatia.com (http://anuragbhatia.com)
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 On Wed, Oct 28, 2020 at 4:26 PM Ryan Hamel <ryan@rkhtech.org> wrote:
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 On Oct 28 2020, at 11:33 am, Anurag Bhatia <me@anuragbhatia.com> wrote:
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.
1. 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.
2. 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.
-- Anurag Bhatia anuragbhatia.com
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. On Thu, Oct 29, 2020 at 2:01 AM Neil Hanlon <neil@shrug.pw> wrote:
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
On Wed, Oct 28, 2020 at 4:26 PM Ryan Hamel <ryan@rkhtech.org> wrote:
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 On Oct 28 2020, at 11:33 am, Anurag Bhatia <me@anuragbhatia.com> wrote:
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.
1. 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.
2. 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.
-- Anurag Bhatia anuragbhatia.com
-- Anurag Bhatia anuragbhatia.com
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? On Wed, Oct 28, 2020 at 1:42 PM Anurag Bhatia <me@anuragbhatia.com> wrote:
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.
On Thu, Oct 29, 2020 at 2:01 AM Neil Hanlon <neil@shrug.pw> wrote:
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
On Wed, Oct 28, 2020 at 4:26 PM Ryan Hamel <ryan@rkhtech.org> wrote:
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 On Oct 28 2020, at 11:33 am, Anurag Bhatia <me@anuragbhatia.com> wrote:
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.
1. 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.
2. 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.
-- Anurag Bhatia anuragbhatia.com
-- Anurag Bhatia anuragbhatia.com
No such feature when running in AP mode. AP mode gives options of wireless settings (SSID etc) and IP for management of the device. On Thu, Oct 29, 2020 at 2:17 AM TJ Trout <tj@pcguys.us> wrote:
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?
On Wed, Oct 28, 2020 at 1:42 PM Anurag Bhatia <me@anuragbhatia.com> wrote:
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.
On Thu, Oct 29, 2020 at 2:01 AM Neil Hanlon <neil@shrug.pw> wrote:
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
On Wed, Oct 28, 2020 at 4:26 PM Ryan Hamel <ryan@rkhtech.org> wrote:
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 On Oct 28 2020, at 11:33 am, Anurag Bhatia <me@anuragbhatia.com> wrote:
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.
1. 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.
2. 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.
-- Anurag Bhatia anuragbhatia.com
-- Anurag Bhatia anuragbhatia.com
-- Anurag Bhatia anuragbhatia.com
On Wed, Oct 28, 2020 at 1:57 PM Anurag Bhatia <me@anuragbhatia.com> wrote:
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 -- Hire me! https://bill.herrin.us/resume/
On Thu 29 Oct 2020 02:10:25 GMT, Anurag Bhatia wrote:
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. :-)
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? -- Alarig
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#
From my client behind Asus Wifi AP:
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. On Thu, Oct 29, 2020 at 3:13 PM Alarig Le Lay <alarig@swordarmor.fr> wrote:
On Thu 29 Oct 2020 02:10:25 GMT, Anurag Bhatia wrote:
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. :-)
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?
-- Alarig
-- Anurag Bhatia anuragbhatia.com
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. On Mon, Nov 2, 2020 at 10:09 PM Anurag Bhatia <me@anuragbhatia.com> wrote:
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#
From my client behind Asus Wifi AP:
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.
On Thu, Oct 29, 2020 at 3:13 PM Alarig Le Lay <alarig@swordarmor.fr> wrote:
On Thu 29 Oct 2020 02:10:25 GMT, Anurag Bhatia wrote:
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. :-)
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?
-- Alarig
-- Anurag Bhatia anuragbhatia.com
-- Anurag Bhatia anuragbhatia.com
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. From: NANOG <nanog-bounces+tony=wicks.co.nz@nanog.org> On Behalf Of Anurag Bhatia Sent: Thursday, 5 November 2020 7:03 am To: NANOG Mailing List <nanog@nanog.org> Subject: {Disarmed} Re: Asus wifi AP re-writing DNS packets Hello An update on this issue: Going through (long) Asus support channel, they first agreed that this was intentional to make router.asus.com <http://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.
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. On Wed, Nov 4, 2020 at 2:33 PM Tony Wicks <tony@wicks.co.nz> wrote:
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.
*From:* NANOG <nanog-bounces+tony=wicks.co.nz@nanog.org> *On Behalf Of *Anurag Bhatia *Sent:* Thursday, 5 November 2020 7:03 am *To:* NANOG Mailing List <nanog@nanog.org> *Subject:* {Disarmed} Re: Asus wifi AP re-writing DNS packets
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.
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. On Wed, Nov 4, 2020 at 11:34 AM Tony Wicks <tony@wicks.co.nz> wrote:
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.
*From:* NANOG <nanog-bounces+tony=wicks.co.nz@nanog.org> *On Behalf Of *Anurag Bhatia *Sent:* Thursday, 5 November 2020 7:03 am *To:* NANOG Mailing List <nanog@nanog.org> *Subject:* {Disarmed} Re: Asus wifi AP re-writing DNS packets
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.
-- -george william herbert george.herbert@gmail.com
On Thu, Oct 29, 2020 at 1:54 AM Ryan Hamel <ryan@rkhtech.org> wrote:
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.
Ryan On Oct 28 2020, at 11:33 am, Anurag Bhatia <me@anuragbhatia.com> wrote:
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.
1. 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.
2. 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.
-- Anurag Bhatia anuragbhatia.com
-- Anurag Bhatia anuragbhatia.com
participants (9)
-
Alarig Le Lay
-
Anurag Bhatia
-
George Herbert
-
Neil Hanlon
-
Ryan Hamel
-
TJ Trout
-
Tony Wicks
-
Verdi R-D
-
William Herrin