Firewall Accepted packets not being logged

[JustinDevelops]

Hello - New to the forums and have been using ASUSMerlin since about a week after I got my Asus router early last year. I recently updated to 380.64 & then 380.64-1 and noticed that the accepted packets have not been logged since the .64 upgrade even though "Logged packets type" is set to BOTH.

I thought it might have been some old setting so I did a factory reset and manually setup everything again and I am seeing the same behavior. I have a ac68u model.

Has anyone else seen this behavior?

- Justin

 

[JustinDevelops]

I thought I would add that I am using SSH on the router to change any settings in nvram. All my changes have been done via gui so far.

 

[JustinDevelops]

No responses but I still want to keep this updating in hopes someone comes along to help.

I have installed the latest firmware and I am still not seeing any Accepted packets logged. I tested it this time by turning all firewall packet logging, then turned on only DROP and it worked, only ACCEPTED and nothing, BOTH and it only showed dropped in the logs.

 

[JustinDevelops]

I just updated to the latest stable firmware 380.65 and I am still seeing the same problems with only DROP being logged and not ACCEPT.

 

[dvohwinkel]

when you upgraded did you reset to factory defaults?

 

[JustinDevelops]

Today when I upgraded from 380.65 I did not. All of the other times and when testing it out I did.

 

[Fitz Mutch]

... still seeing the same problems with only DROP being logged and not ACCEPT.

If you're seeing in syslog, "net_ratelimit: N callbacks suppressed", the syslog messages are too fast or too many. How to tell the kernel to not throttle the syslog messages. This could fill up the syslog quickly.

# disable syslog rate limit
/bin/echo 0 > /proc/sys/net/core/message_cost

 

[JustinDevelops]

If you're seeing in syslog, "net_ratelimit: N callbacks suppressed", the syslog messages are too fast or too many. How to tell the kernel to not throttle the syslog messages. This could fill up the syslog quickly.

# disable syslog rate limit
/bin/echo 0 > /proc/sys/net/core/message_cost

Thanks for suggestion, nothing like that I can see in the syslog.

 

[john9527]

Have you added any custom iptables rules or other addon packages? Depending on how it's done, it can prevent the logging.

 

[JustinDevelops]

Have you added any custom iptables rules or other addon packages? Depending on how it's done, it can prevent the logging.

Not that I am aware of.

One of the times I was trying to trouble shoot the issue I enabled ssh and then ran "# nvram set log_accepted=1" which I read about on this site https://fatmin.com/2015/01/04/configure-syslog-logging-levels-on-the-asus-rt-ac66u-router, that seemed to change nothing. I have performed a factory reset once or twice since then.

 

[john9527]

Not that I am aware of.

One of the times I was trying to trouble shoot the issue I enabled ssh and then ran "# nvram set log_accepted=1" which I read about on this site https://fatmin.com/2015/01/04/configure-syslog-logging-levels-on-the-asus-rt-ac66u-router, that seemed to change nothing. I have performed a factory reset once or twice since then.

There's no such setting as log_accepted, so that's why it did nothing. What's the value of
nvram get fw_log_x

EDIT: Also append the output of
iptables -S | grep logaccept

EDIT2: Also check that the Log entries greater than is set to the default of Debug on the Administration page

 

[JustinDevelops]

There's no such setting as log_accepted, so that's why it did nothing. What's the value of
nvram get fw_log_x

EDIT: Also append the output of
iptables -S | grep logaccept

EDIT2: Also check that the Log entries greater than is set to the default of Debug on the Administration page

value of nvram get fw_log_x = fw_log_x=both

"Default message log level" & "Log only messages more urgent than" are both set to default in the admin tool.

Here is the output of iptables -S | grep logaccept

-N logaccept
-A INPUT -m state --state RELATED,ESTABLISHED -j logaccept
-A INPUT -p icmp -m icmp ! --icmp-type 8 -j logaccept
-A FORWARD -m state --state RELATED,ESTABLISHED -j logaccept
-A FORWARD -i br0 -o br0 -j logaccept
-A FORWARD -m conntrack --ctstate DNAT -j logaccept
-A PControls -j logaccept
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT

 

[john9527]

Well....so far I'm at a loss.....all the pieces look correct. Next step....append the output of

iptables -nvL

(please put it in a code insert to avoid formatting problems)

 

[JustinDevelops]

Sorry about that, I knew better. Wife was waiting at the door to leave for dinner.
I fixed the above.

Below is the next output, I could spend an hour or so tomorrow to factory reset everything again to see if reseting with the latest firmware fixes my issues. I should also look into learning more about iptables for reasons like these.

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 logdrop    icmp --  vlan2  *       0.0.0.0/0            0.0.0.0/0            icmptype 8
  233 56028 logaccept  all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    1    44 logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
   28  3895 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW
  182 40363 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0            state NEW
    0     0 logaccept  icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmp !type 8
    4   164 logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   16   982 logaccept  all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 logdrop    all  --  !br0   vlan2   0.0.0.0/0            0.0.0.0/0           
    0     0 logdrop    all  --  vlan2  *       0.0.0.0/0            0.0.0.0/0            state INVALID
    0     0 logaccept  all  --  br0    br0     0.0.0.0/0            0.0.0.0/0           
    0     0 SECURITY   all  --  vlan2  *       0.0.0.0/0            0.0.0.0/0           
    2   104 NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 logaccept  all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
    2   104 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 447 packets, 111K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FUPNP (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain NSFW (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain PControls (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 logaccept  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain SECURITY (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02 limit: avg 1/sec burst 5
    0     0 logdrop    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02
    0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04 limit: avg 1/sec burst 5
    0     0 logdrop    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8 limit: avg 1/sec burst 5
    0     0 logdrop    icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain logaccept (6 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "ACCEPT "
  249 57010 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain logdrop (8 references)
 pkts bytes target     prot opt in     out     source               destination         
    4   164 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "DROP "
    5   208 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

 

[RMerlin]

Works for me. Try disabling NAT acceleration.

 

[JustinDevelops]

I tried that same results.
I have just now performed a factory reset from with the Administration - Restore/Save/Upload Setting area and I have only setup my ISP required info, and two dummy wifi networks mostly just to setup a secure password while trying all of this.

I have also only enabled Firewall logging both BOTH, and under logging in admin tool I have it set to Debug & All curretly to see if that helped. I noticed last time I had the DDoS protection turned on for the firewall but I have it off now to see if that was an issue.

With this all done I am still getting no ACCEPT packets in the syslog.

I did just ssh in and ran "nvram show | grep log" would the console_loglevel=5 be causing it? If that is talking about the System Log> General Log I was seeing accepted messages in there at one time as well as in my Splunk system.

dhcpd_querylog=1
log_port=514
webdav_last_login_info=
message_loglevel=7
log_size=256
size: 49201 bytes (16335 left)
vpn_loglevel=3
log_level=8
PM_attach_modemlog=
pushnotify_httplogin=1
http_autologout=30
PM_attach_syslog=
console_loglevel=5
fw_log_x=both

 

[RMerlin]

I would expect both DROP and ACCEPT logging to use the same logging level, so no other idea here, sorry. Only thing that crossed my mind would be if you used a VPN server, which might bypass portions of your firewall.

 

[john9527]

Log levels look OK.....

Just for fun, try entering this command then check the syslog

iptables -I NSFW -j logaccept

 

[JustinDevelops]

I would expect both DROP and ACCEPT logging to use the same logging level, so no other idea here, sorry. Only thing that crossed my mind would be if you used a VPN server, which might bypass portions of your firewall.

Only one computer on the network is using a VPN and thats my work computer. But I do see the thought behind that.

 

[JustinDevelops]

Log levels look OK.....

Just for fun, try entering this command then check the syslog

iptables -I NSFW -j logaccept

Command ran and now have ACCEPT showing in the console and my splunk server!

Thank you for helping @john9527 It looks like it added logaccept to the the Chain NSFW but whats NSFW? Only searches I come back with are the typical NSFW on images meaning.