What's new

RT-N56U - firewall logging causes serious slowdown

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

O

Ormu

Guest
I installed RT-N56U for my parents and did the Shields Up test to check that security stuff was OK. I noticed that when the firewall was set to log dropped packets the router got extremely slow when probing was in progress. Trying to browse internet, trying to access the admin panel, even trying to ping the router was nearly impossible. When I turned logging off everything went fine.

I think this is a serious problem that should be reported to Asus - what is the best way to do it? I'm almost sure that this is a bug - could that test really cause the router to overload when it is working properly? It's attached to a 8/1M ADSL line via a bridge modem and I can't believe that 8Mb/s would do anything. Firmware is latest.
 
I installed RT-N56U for my parents and did the Shields Up test to check that security stuff was OK. I noticed that when the firewall was set to log dropped packets the router got extremely slow when probing was in progress. Trying to browse internet, trying to access the admin panel, even trying to ping the router was nearly impossible. When I turned logging off everything went fine.

I think this is a serious problem that should be reported to Asus - what is the best way to do it? I'm almost sure that this is a bug - could that test really cause the router to overload when it is working properly? It's attached to a 8/1M ADSL line via a bridge modem and I can't believe that 8Mb/s would do anything. Firmware is latest.

I doubt this is the cause of your issues, all that option does is add the following iptables rule to the drop chain which has no performance impact (On Padavans firmware atleast)

iptables -I logdrop -m state --state NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
 
To my opinion logging of Firewall packets makes no sense as permanent setting.
It is good to temproray set on during a probe test as described, although Shields-up reports the ports found open.
The Shields-up test sends quite a lot of packages to the router, the logging action takes time for sure, for many log items the time can pile up considerably.
So will a DDOS attack to your router, the good work of the firewall takes CPU time, untill there is no more time to pass on the good traffic.
With the firewall on, no port forwaring and UPnP set to No, there won't be much reason to worry.
Keep an eye on bugfixes in the router firmware, update if security fixes are available and keep in mind that stock firmware has no IPv6 firewall.
 
Last edited:
I doubt this is the cause of your issues, all that option does is add the following iptables rule to the drop chain which has no performance impact (On Padavans firmware atleast)

I tested it multiple times and it seems to be the cause - if logging is disabled then there's no slowdown.

I have RT-N66U and it does not slow down during Shields Up test even though it's connected to a 100/10M line and logging is on all the time.


To my opinion logging of Firewall packets makes no sense as permanent setting.
It is good to temproray set on during a probe test as described, although Shields-up reports the ports found open.
The Shields-up test sends quite a lot of packages to the router, the logging action takes time for sure, for many log items the time can pile up considerably.
So will a DDOS attack to your router, the good work of the firewall takes CPU time, untill there is no more time to pass on the good traffic.
With the firewall on, no port forwaring and UPnP set to No, there won't be much reason to worry.
Keep an eye on bugfixes in the router firmware, update if security fixes are available and keep in mind that stock firmware has no IPv6 firewall.

I'd like to keep logging on if it doesn't cause problems - that way I could at least get some evidence in the unlikely case of a DDOS attack.

Does Asus have any bug report channel where I could report this problem?
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top