iptables pkts & bytes numbers are too low on Merlin 3004.388

[v.y.k]

Hi

iptables pkts & bytes numbers on Merlin 3004.388

# iptables -L INPUT -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1707  134K INPUT_PING icmp --  any    any     anywhere             anywhere             icmp echo-request
 222K   37M logaccept  all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
 2568  218K logdrop    all  --  any    any     anywhere             anywhere             state INVALID
 548K  122M PTCSRVWAN  all  --  !br0   any     anywhere             anywhere           
 148K   21M PTCSRVLAN  all  --  br0    any     anywhere             anywhere           
 148K   21M ACCEPT     all  --  br0    any     anywhere             anywhere             state NEW
 546K  122M ACCEPT     all  --  lo     any     anywhere             anywhere             state NEW
 1639  260K WGSI       all  --  any    any     anywhere             anywhere           
 1639  260K WGCI       all  --  any    any     anywhere             anywhere           
 1639  260K OVPNSI     all  --  any    any     anywhere             anywhere           
 1639  260K OVPNCI     all  --  any    any     anywhere             anywhere           
 1639  260K logdrop    all  --  any    any     anywhere             anywhere

The values look a bit small compare to iptables pkts & bytes on Merlin 386
The same number were a bit larger (ie MBytes -> GBytes)

Did something change?

Another example:

# iptables -L FORWARD -v
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 416K   97M IPSEC_DROP_SUBNET_ICMP  all  --  any    any     anywhere             anywhere
 416K   97M IPSEC_STRONGSWAN  all  --  any    any     anywhere             anywhere
 364K   71M logaccept  all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
51782   26M WGSF       all  --  any    any     anywhere             anywhere
51782   26M OVPNSF     all  --  any    any     anywhere             anywhere
   55  3697 logaccept  all  --  br0    br0     anywhere             anywhere
 1593 80712 logdrop    all  --  any    any     anywhere             anywhere             state INVALID
50134   26M WGCF       all  --  any    any     anywhere             anywhere
50134   26M OVPNCF     all  --  any    any     anywhere             anywhere
50134   26M VPNCF      all  --  any    any     anywhere             anywhere
50134   26M ACCEPT     all  --  br0    any     anywhere             anywhere

 

[RMerlin]

Did something change?

Yes, your uptime.

These counters will get reset whenever the firewall is restarted.

 

[v.y.k]

Yes, your uptime.

These counters will get reset whenever the firewall is restarted.

Uptime	6 days 8 hour(s) 4 minute(s) 26 seconds

 

[v.y.k]

Did not find anything on restart of firewall in the logs for the past 3 days.
I will restart Router and monitor for the next few days

 

[ColinTaylor]

The traffic counters are not being updated correctly because flow control is enabled. If you disable flow control the numbers will be correct.

fc disable
fc flush

 

[v.y.k]

The traffic counters are not being updated correctly because flow control is enabled. If you disable flow control the numbers will be correct.

fc disable
fc flush

Thanks, it worked

 

[v.y.k]

@ColinTaylor

Is this just a traffic counters counting issue or actually some traffic packets are not using firewall?

 

[ColinTaylor]

It's just a traffic counter issue.

 

[RMerlin]

@ColinTaylor

Is this just a traffic counters counting issue or actually some traffic packets are not using firewall?

Packets can skip parts of Netfilter, like the FORWARD chain, when using flow acceleration. That's why some features do not work with acceleration enabled, as these features may require firewall rules to be hit consistently by traffic.

The old NAT acceleration was called CTF, which meant Cut-Through Forwarding, for instance.

 

[v.y.k]

Packets can skip parts of Netfilter, like the FORWARD chain, when using flow acceleration. That's why some features do not work with acceleration enabled, as these features may require firewall rules to be hit consistently by traffic.

The old NAT acceleration was called CTF, which meant Cut-Through Forwarding, for instance.

Is it possible to find out which part of the firewall chains/rules, packets are not allowed to skip (ie INPUT)?

 

[ColinTaylor]

Is it possible to find out which part of the firewall chains/rules, packets are not allowed to skip (ie INPUT)?

What are your specific concerns? My understanding is it's not "skipping" any of the rules as such. So for example, if you had a rule that blocked a certain destination IP that would still apply.

 

[v.y.k]

it's not "skipping" any of the rules as such

If this is true, there is no concern

 

[RMerlin]

What are your specific concerns? My understanding is it's not "skipping" any of the rules as such. So for example, if you had a rule that blocked a certain destination IP that would still apply.

Rules in certain chains can be skipped if they go through CTF/FC.

The INPUT chain that handles security/firewall will be fine.

Is it possible to find out which part of the firewall chains/rules, packets are not allowed to skip (ie INPUT)?

It's not documented, as these technologies are proprietary/confidential. Only Broadcom would know the details.

 

[v.y.k]

@RMerlin

Thanks for the information