Mailing List Archive

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
>
>

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

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