Re: {Disarmed} Re: Asus wifi AP re-writing DNS packets
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 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 *On Behalf Of *Anurag
> Bhatia
> *Sent:* Thursday, 5 November 2020 7:03 am
> *To:* NANOG Mailing List
> *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.
>
>
>
>
>
>
>
Re: {Disarmed} Re: Asus wifi AP re-writing DNS packets
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 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 *On Behalf Of *Anurag
> Bhatia
> *Sent:* Thursday, 5 November 2020 7:03 am
> *To:* NANOG Mailing List
> *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.herb...@gmail.com
RE: {Disarmed} Re: Asus wifi AP re-writing DNS packets
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 On Behalf Of Anurag
Bhatia
Sent: Thursday, 5 November 2020 7:03 am
To: NANOG Mailing List
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.
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. Thanks. On Mon, Nov 2, 2020 at 10:09 PM Anurag Bhatia 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/0udp dpt:53 > 0 0 ACCEPT tcp -- * * 0.0.0.0/0 > 0.0.0.0/0tcp 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/0udp dpt:53 > 0 0 ACCEPT tcp -- * * 0.0.0.0/0 > 0.0.0.0/0tcp 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/0tcp dpt:53 > 0 0 ACCEPT udp -- * * 0.0.0.0/0 > 0.0.0.0/0udp 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 > 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
Re: Asus wifi AP re-writing DNS packets
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/0udp dpt:53 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0tcp 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/0udp dpt:53 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0tcp 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/0tcp dpt:53 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0udp 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 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
Re: Asus wifi AP re-writing DNS packets
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
Re: Asus wifi AP re-writing DNS packets
On Wed, Oct 28, 2020 at 1:57 PM Anurag Bhatia 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/
Re: Asus wifi AP re-writing DNS packets
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 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 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 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 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 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
Re: Asus wifi AP re-writing DNS packets
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 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 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 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 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 >
Re: Asus wifi AP re-writing DNS packets
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 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 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 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
Re: Asus wifi AP re-writing DNS packets
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 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 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 > >
Re: Asus wifi AP re-writing DNS packets
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 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) > > > > > > >
Asus wifi AP re-writing DNS packets
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
