Asus wifi AP re-writing DNS packets

Anurag Bhatia me at anuragbhatia.com
Wed Nov 4 18:02:49 UTC 2020


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 at 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 at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20201104/c29792c1/attachment.html>


More information about the NANOG mailing list