What's new
By:

Firewall Accepted packets not being logged

JustinDevelops

JustinDevelops

Occasional Visitor
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
 
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.
 
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.
 
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.
 
when you upgraded did you reset to factory defaults?
 
JustinDevelops said:
... still seeing the same problems with only DROP being logged and not ACCEPT.
Click to expand...
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.
Code: 
# disable syslog rate limit
/bin/echo 0 > /proc/sys/net/core/message_cost
 
Fitz Mutch said:
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.
Code: 
# disable syslog rate limit
/bin/echo 0 > /proc/sys/net/core/message_cost
Click to expand...
Thanks for suggestion, nothing like that I can see in the syslog. :(
 
Have you added any custom iptables rules or other addon packages? Depending on how it's done, it can prevent the logging.
 
john9527 said:
Have you added any custom iptables rules or other addon packages? Depending on how it's done, it can prevent the logging.
Click to expand...
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.
 
JustinDevelops said:
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.
Click to expand...
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
 
Last edited:
john9527 said:
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
Click to expand...

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
Code: 
-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
 
Last edited:
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)
 
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.

Code: 
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
 
Works for me. Try disabling NAT acceleration.
 
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.

Code: 
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
 
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.
 
Log levels look OK.....

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

iptables -I NSFW -j logaccept
 
Last edited:
RMerlin said:
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.
Click to expand...

Only one computer on the network is using a VPN and thats my work computer. But I do see the thought behind that.
 
john9527 said:
Log levels look OK.....

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

iptables -I NSFW -j logaccept
Click to expand...

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.
 
You must log in or register to reply here.

Similar threads

bengalih
PSA - RT-AC68U with CTF/NAT Acceleration may allow IPv6 UDP traffic through firewall
Replies
8
Views
2K
RMerlin
RMerlin
B
BE88U Firewall port forwarding set in GUI not working. Anyone else?
Replies
2
Views
971
Ripshod
Ripshod
B
Skynet Skynet does not fully enforce stealth mode on WAN (ports 80 & 443 show as CLOSED)
Replies
4
Views
885
BeachGuy
B
A
DNS Director not properly redirecting DNS traffic to router
Replies
18
Views
955
degrub
D
B
Firewall lan - vpn?
Replies
0
Views
719
blast
B
Similar threads
Thread starter Title Forum Replies Date
bengalih PSA - RT-AC68U with CTF/NAT Acceleration may allow IPv6 UDP traffic through firewall Asuswrt-Merlin 8
C Firewall URL filter bypassed by guest networks with disabled intranet access Asuswrt-Merlin 4
S Firewall rule to block firmware updates Asuswrt-Merlin 5
D Entware [AX86U Merlin 3004.388.9_2] Disabling Firewall in WebUI allows Transmission to open the famous closed port, but WebUI Port Forwarding does not. Asuswrt-Merlin 1
R ipv6 / firewall on ax86u pro (on latest Merlin) Asuswrt-Merlin 6
B BE88U Firewall port forwarding set in GUI not working. Anyone else? Asuswrt-Merlin 2
W Whitelisting VoIP IP addresses Firewall Asuswrt-Merlin 1
L strange problem router not passing packets when connect via secondary access points Asuswrt-Merlin 2
C Receiving packets with own address as source address Asuswrt-Merlin 6

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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

Members online

Total: 1,849 (members: 17, guests: 1,832)
Back
Top
✖