Firewall Accepted packets not being logged

[john9527]

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.

This was an educated guess based on your iptables -nvL output. @RMerlin recently made a change to fix a bug in the Network Services Filter (NSFW) and left the chain empty if no filters were defined. It looks like the chain may need to be terminated with an ACCEPT/logaccept or the main FORWARD chain terminated with a logaccept.

BTW.....as a temporary fix, change the command slightly to

iptables -A NSFW -j logaccept

and add it to or create a /jffs/scripts/firewall-start

 

[JustinDevelops]

This was an educated guess based on your iptables -nvL output. @RMerlin recently made a change to fix a bug in the Network Services Filter (NSFW) and left the chain empty if no filters were defined. It looks like the chain may need to be terminated with an ACCEPT/logaccept or the main FORWARD chain terminated with a logaccept.

BTW.....as a temporary fix, change the command slightly to

iptables -A NSFW -j logaccept

and add it to or create a /jffs/scripts/firewall-start

Right on, do you think I should file this bug in github for the project?

I have not created any extra scripts for the router. Is the /jffs/scripts/firewall-start just a blank file with "iptables -A NSFW -j logasscept" on the first line, or do I need to add bash indicator etc at top?

 

[john9527]

Right on, do you think I should file this bug in github for the project?

I have not created any extra scripts for the router. Is the /jffs/scripts/firewall-start just a blank file with "iptables -A NSFW -j logasscept" on the first line, or do I need to add bash indicator etc at top?

I called out RMerlin in the response....he'll see it.

/jffs/scripts/firewall-start is a normal script (without a .sh extension) that needs the shebang as the first line and must be marked as executable. You can read more about user scripts in the wiki
https://github.com/RMerl/asuswrt-merlin/wiki/User-scripts

 

[JustinDevelops]

I called out RMerlin in the response....he'll see it.

/jffs/scripts/firewall-start is a normal script (without a .sh extension) that needs the shebang as the first line and must be marked as executable. You can read more about user scripts in the wiki
https://github.com/RMerl/asuswrt-merlin/wiki/User-scripts

OK Sounds good on bug report. Thank you again helping me debug my issue and the script link.

 

[RMerlin]

Adding a blind jump to logaccept is the wrong thing to do, as it basically tells the firewall to accept anything, ignoring the default policy which is to DROP packets when they do not match any rule.

An empty chain will merely return control to the calling chain, which is FORWARD. So not having a default rule in NSF is also intended.

What is more suspicious is rather the final rule of the FORWARD chain:

81 18238 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0

 

[JustinDevelops]

Adding a blind jump to logaccept is the wrong thing to do, as it basically tells the firewall to accept anything, ignoring the default policy which is to DROP packets when they do not match any rule.

An empty chain will merely return control to the calling chain, which is FORWARD. So not having a default rule in NSF is also intended.

What is more suspicious is rather the final rule of the FORWARD chain:

81 18238 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0

OK that doesn't sound good, so I just removed that script and rebooted. Now ACCEPT is no longer being shown.

Can you expand on your concern on that rule? I am very green to all of this and just started messing with it when I noticed ACCEPT wasn't being logged anymore.

 

[john9527]

What is more suspicious is rather the final rule of the FORWARD chain:

No, I think that's correct.....it's accepting the forward only from input br0 (the local LAN)...any thing from the external interfaces will be dropped.

 

[RMerlin]

No, I think that's correct.....it's accepting the forward only from input br0 (the local LAN)...any thing from the external interfaces will be dropped.

I mean the fact that it jumps to ACCEPT rather than logaccept.

I see Asus was also doing the same, so it looks like a bug from upstream. I just changed it to use logaccept instead of ACCEPT.

 

[JustinDevelops]

What would I change now to fix it on my device?

 

[john9527]

@RMerlin but look at post #14.....the rule immediately after the jump to NSFW is a logaccept. So it looks that the empty NSF chain isn't returning????

@JustinDevelops - try changing the added rule to -j RETURN instead of -j logaccept

 

[RMerlin]

Another thing that makes even less sense. We have rules like this:

 360 45153 logaccept  all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

However, if you look at logaccept, it shows this:

    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "ACCEPT "

Looks like the whole logging is a bit fubar in general...

 

[RMerlin]

@RMerlin but look at post #14.....the rule immediately after the jump to NSFW is a logaccept. So it looks that the empty NSF chain isn't returning????

Returning does work, look at my packet counts on these two rules:

   2  1454 NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0          
    2  1454 triggers   all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

That's with an empty NSFW chain.

 

[john9527]

Right...better explanation is that the logaccept rule isn't triggering on the return

EDIT: Ahhh.....look at post #12....the logaccept rule is only triggering on cstate DNAT

 

[RMerlin]

Right...better explanation is that the logaccept rule isn't triggering on the return

That's because there's no rule below that with a logaccept target. If you are looking into logging outbound connections, that's why the bug lies with the rule I quoted in post #25 - this jumps to ACCEPT instead of logaccept.

 

[RMerlin]

What would I change now to fix it on my device?

These two commands should fix it:

iptables -D FORWARD -i br0 -j ACCEPT
iptables -A FORWARD -i br0 -j logaccept

Sample output:

Mar  1 01:19:44 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.10.106 DST=91.189.89.198 LEN=76 TOS=0x10 PREC=0x00 TTL=63 ID=31655 DF PROTO=UDP SPT=59706 DPT=123 LEN=56 
Mar  1 01:19:46 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.10.2 DST=8.8.8.8 LEN=68 TOS=0x00 PREC=0x00 TTL=63 ID=19717 DF PROTO=UDP SPT=40726 DPT=53 LEN=48 
Mar  1 01:19:46 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.10.2 DST=129.128.12.20 LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=19732 DF PROTO=UDP SPT=57976 DPT=123 LEN=56

 

[john9527]

@RMerlin - I think I see something else....compare post 12 and 14.....the iptables output in 14 is missing the logaccept rule for state RELATED, ESTABLISHED

EIDT: That rule is the one really triggering on my fork.

EDIT2: Take that back, it's the first rule....and shows it's triggering. The question is why no output?

 

[RMerlin]

@RMerlin - I think I see something else....compare post 12 and 14.....the iptables output in 14 is missing the logaccept rule for state RELATED, ESTABLISHED

EIDT: That rule is the one really triggering on my fork.

EDIT2: Take that back, it's the first rule....and shows it's triggering. The question is why no output?

Jumping to logaccept on RELATED,ESTABLISHED makes no sense, because the logaccept chain will only log on a NEW state. Which is what you'd want, otherwise you'd get a log entry for every single packet. See post #31.

 

[john9527]

Jumping to logaccept on RELATED,ESTABLISHED makes no sense, because the logaccept chain will only log on a NEW state. Which is what you'd want, otherwise you'd get a log entry for every single packet. See post #31.

Yep...stream of consciousness on my part

But I've been trying some things on my fork for comparison, and I think the logs may be getting lost in the SECURITY chain.

@JustinDevelops - Can you try disabling DOS protection under Firewall and see if it changes things?

 

[JustinDevelops]

@JustinDevelops - Can you try disabling DOS protection under Firewall and see if it changes things?

@john9527 sorry for the delay, I missed the last notification. I just disabled the DOS protection and still no accept showing up. Right now my firewall gui settings are as such. I also tried NAT Loopback in all three options.
Enable Firewall Yes -
Enable DoS protection - No
Logged packets type - Both
Respond ICMP Echo (ping) Request from WAN - No
NAT Loopback - Asus

I compared before and after iptable -nvL and this was removed from FORWARD. I re-enabled it and my iptable -vnL output is the same as post #14. With no ACCEPT showing in the log.

    0     0 SECURITY   all  --  vlan2  *       0.0.0.0/0            0.0.0.0/0

 

[RMerlin]

But I've been trying some things on my fork for comparison, and I think the logs may be getting lost in the SECURITY chain.

Here, the SECURITY chain contains only DROP and RETURN destinations. Maybe the kernel changes Asus applied in 7266 might be what's needed for it to work properly for you?

https://github.com/RMerl/asuswrt-me...de71382#diff-093ed4eb165658a41615f55275ad1db8