Re: Asus wifi AP re-writing DNS packets

[William Herrin]

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

[Anurag Bhatia]

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

[TJ Trout]

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

[Anurag Bhatia]

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

[Neil Hanlon]

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

[Ryan Hamel]

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

[Anurag Bhatia]

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: plea for comcast/sprint handoff debug help

[Lukas Tribus]

Hello,

On Wed, 28 Oct 2020 at 16:58, Randy Bush  wrote:
> tl;dr: diagnosed by comcast.  see our short paper to be presented at imc
>tomorrow https://archive.psg.com/200927.imc-rp.pdf
>
> lesson: route origin relying party software may cause as much damage as
> it ameliorates

There is a myth that ROV is inherently fail-safe (it isn't if your
production routers have stale VRP's) which leads to the assumption
that proper monitoring is neglectable.

I'm working on a shell script using rtrdump to detect stale RTR
servers (based on serial changes and the actual data). Of course this
would never detect partial failures that affect only some child-CAs,
but it does detect a hung RTR server (or a standalone RTR server where
the validator validates no more).


lukas

Re: plea for comcast/sprint handoff debug help

[Randy Bush]

> tl;dr:
> 
> comcast: does your 50.242.151.5 westin router receive the announcement
> of 147.28.0.0/20 from sprint's westin router 144.232.9.61?

tl;dr: diagnosed by comcast.  see our short paper to be presented at imc
   tomorrow https://archive.psg.com/200927.imc-rp.pdf

lesson: route origin relying party software may cause as much damage as
it ameliorates

randy

plea for comcast/sprint handoff debug help

[Randy Bush]

tl;dr:

comcast: does your 50.242.151.5 westin router receive the announcement
of 147.28.0.0/20 from sprint's westin router 144.232.9.61?

details:

3130 in the westin announces
  147.28.0.0/19 and
  147.28.0.0/20
to sprint, ntt, and the six
and we want to remove the /19

when we stop announcing the /19, a traceroute to comcast through sprint
dies at the handoff from sprint to comcast.

r0.sea#traceroute 73.47.196.134 source 147.28.7.1
Type escape sequence to abort.
Tracing the route to c-73-47-196-134.hsd1.ma.comcast.net (73.47.196.134)
VRF info: (vrf in name/id, vrf out name/id)
  1 r1.sea.rg.net (147.28.0.5) 0 msec 1 msec 0 msec
  2 sl-mpe50-sea-ge-0-0-3-0.sprintlink.net (144.232.9.61) [AS 1239] 1 msec 1 
msec 0 msec
  3  *  *  * 
  4  *  *  * 
  5  *  *  * 
  6  *  *  *

this would 'normally' (i.e. when the /19 is announced) be

r0.sea#traceroute 73.47.196.134 source 147.28.7.1
Type escape sequence to abort.
Tracing the route to c-73-47-196-134.hsd1.ma.comcast.net (73.47.196.134)
VRF info: (vrf in name/id, vrf out name/id)
  1 r1.sea.rg.net (147.28.0.5) 0 msec 1 msec 0 msec
  2 sl-mpe50-sea-ge-0-0-3-0.sprintlink.net (144.232.9.61) [AS 1239] 1 msec 0 
msec 1 msec
  3 be-207-pe02.seattle.wa.ibone.comcast.net (50.242.151.5) [AS 7922] 1 msec 0 
msec 0 msec
  4 be-10847-cr01.seattle.wa.ibone.comcast.net (68.86.86.225) [AS 7922] 1 msec 
1 msec 2 msec
  etc
  
specifically, when 147.28.0.0/19 is announced, traceroute from
147.28.7.2 through sprint works to comcast.  withdraw 147.28.0.0/19,
leaving only 147.28.0.0/20, and the traceroute enters sprint but fails
at the handoff to comcast.  Bad next-hop?  not propagated?  covid?
magic?

which is why we wonder what comcast (50.242.151.5) hears from sprint at
that handoff

note that, at the minute, both the /19 and the /20 are being announced,
as we want things to work.  so you will not be able to reproduce.

so, comcast, are you receiving the announcement of the /20 from sprint?
with a good next-hop?

randy

Data Center Address

[Rod Beck]

Can anyone familiar with SG2 Equinix tell me if that is where the trading 
engine for the Singapore Stock Exchange is located?


Roderick Beck

VP of Business Development

United Cable Company

www.unitedcablecompany.com

New York City & Budapest

rod.b...@unitedcablecompany.com

Budapest: 36-70-605-5144

NJ: 908-452-8183


[1467221477350_image005.png]