On 1/23/2021 6:18 PM, Matthew Collins wrote:
> Many apologies, I was called away for a couple days.
> 
> Many thanks for the patch!
> 
> Good news and bad news... the patch applies successfully (of course
> :-) ), #shorewall restart -C -f now mentions 'counters' in the
> iptables-restore line (as does #shorewall start -C -f)... but counters
> are still cleared:
> 
> [matt@homeserver Shorewall]$ sudo patch -p 3
> /usr/share/shorewall/Shorewall/Chains.pm
> ~/code-master-1-21.01.21.16.26.19-rfc.patch
> patching file /usr/share/shorewall/Shorewall/Chains.pm

I revert this patch, see below.

> [matt@homeserver Shorewall]$ sudo shorewall save -C
>    Currently-running Configuration Saved to /var/lib/shorewall/restore
> [matt@homeserver Shorewall]$ sudo shorewall show ipa
> Shorewall 5.2.8 per-IP Accounting at homeserver - Sat 23 Jan 14:19:42 GMT 2021
> 
> Showing table: loc
> IP: 192.168.1.10 SRC packets: 146357 bytes: 51338604 DST packets:
> 147839 bytes: 97006413
> IP: 192.168.1.51 SRC packets: 94268 bytes: 46097562 DST packets:
> 208820 bytes: 234135327
> IP: 192.168.1.52 SRC packets: 7612 bytes: 1665727 DST packets: 8627
> bytes: 4504117
> IP: 192.168.1.60 SRC packets: 48884 bytes: 25335363 DST packets: 49155
> bytes: 45306629
> IP: 192.168.1.70 SRC packets: 945 bytes: 91292 DST packets: 0 bytes: 0
> IP: 192.168.1.79 SRC packets: 49381 bytes: 4097282 DST packets: 55188
> bytes: 50986444
> IP: 192.168.1.91 SRC packets: 2834 bytes: 2156472 DST packets: 2834
> bytes: 1314774
> IP: 192.168.1.104 SRC packets: 1865 bytes: 210304 DST packets: 2268
> bytes: 844187
> 
> [matt@homeserver Shorewall]$ sudo shorewall restart -C -f
> Stopping Shorewall....
> Processing /etc/shorewall/stop ...
> Processing /etc/shorewall/tcclear ...
> Preparing iptables-restore input...
> Running /sbin/iptables-restore --wait 60...
> IPv4 Forwarding Enabled
> Processing /etc/shorewall/stopped ...
> done.
> Starting Shorewall....
> Initializing...
> Processing /etc/shorewall/init ...
> Processing /etc/shorewall/tcclear ...
> Setting up Route Filtering...
> Setting up Martian Logging...
> Setting up Accept Source Routing...
> Setting up Proxy ARP...
> Setting up Traffic Control...
> Preparing iptables-restore input...
> Running /sbin/iptables-restore --counters --wait 60...
> IPv4 Forwarding Enabled
> Processing /etc/shorewall/start ...
> Processing /etc/shorewall/started ...
> done.
> [matt@homeserver Shorewall]$ sudo shorewall show ipa
> Shorewall 5.2.8 per-IP Accounting at homeserver - Sat 23 Jan 14:20:06 GMT 2021
> 
> Showing table: loc
> IP: 192.168.1.10 SRC packets: 6 bytes: 1008 DST packets: 7 bytes: 1184
> IP: 192.168.1.52 SRC packets: 29 bytes: 9938 DST packets: 32 bytes: 6030
> 
> 
> 
> Running '#shorewall restart -C -f && shorewall save -C && less
> /var/lib/shorewall/restore-iptables' multiple times shows that the
> packet/byte counters still seem to be being reset. However, running
> '#iptables-restore --counters /var/lib/shorewall/restore-iptables &&
> shorewall save -C && less /var/lib/shorewall/restore-iptables' is
> keeping the counters!!
> 
> '#shorewall -T restart -C -f' indicates that in fact,
> 'iptables-restore' is being given
> /var/lib/shorewall/.iptables-restore-input, which contains no
> packet/byte counter data (everything is [0:0]). 'reload' seems to
> write counters to this file, but not 'start' or 'restart' (or anything
> else?)
> 
> 
> So, is there a purpose for both 'restore-iptables' and
> '.iptables-restore-input'? 

Both 'Shorewall save' and 'shorewall restore' use 'iptables-restore''
while 'start' and 'reload' use '.iptables-restore-input'.

> Should '#shorewall save -C' write to
> '.iptables-restore-input' instead? 

No because of 'shorewall restore'.

> Should both 'reload' and 'restart'
> write counters? (I can't find the logic that does this, should be in
> Chains.pm? I changed
> https://gitlab.com/shorewall/code/-/blob/master/Shorewall/Perl/Shorewall/Chains.pm#L8805

The URL points to the 'master' branch, where it should point to tag
'5.2.8-base' (nit, as in this case both files are identical):

https://gitlab.com/shorewall/code/-/blob/5.2.8-base/Shorewall/Perl/Shorewall/Chains.pm#L8805

> to
> emit ( 'if [ "$COMMAND" = reload ] || [ "$COMMAND" = restart ] ; then' );
> but doesn't seem to help here)
>

This function is related to 'dinamic', so this is not the first place to
look at and would explain why it does not help!

> Thanks for your help so far, it's much appreciated. If this is getting
> a bit involved, I'm happy to kludge things here to suit me (I rarely
> use 'restart', so can make 'save' write to '.iptables-restore-input'
> to carry counters over a reboot).
> 

You could also use 'save' and 'restore' or see below for 'RESTART' in
shorewall.conf:

I looked a bit more into this and my thoughts are as follows:

The -C ('g_counters') option was introduced in Shorewall 4.x, when
Shorewall 5.x was released the meaning of restart was change from
'reload' to a 'stop' followed by a 'start'.
For compatibility reasons, Shorewall allows to change this back by
changing the value of the 'RESTART' variable to 'reload' in
'shorewall.conf'.

As far as my understanding of the code goes, the -C option is not
supported when the start command is executed but should work when
'RESTART' is set to 'reload in 'shorewall.conf'.

In the function 'define_firewall': when 'reload -C' is executed the file
'.iptables-restore-input' is properly populated.


As iptables is being phased out, I'm not sure if something should be
done to honor the -C option when start is executed.


Note that, this is my understanding of the situation and  I could also
be completely wrong about it!


I'm open to suggestion/feedbac and there is no ETA for a new release of
Shorewall.

-- 
Matt Darfeuille <m...@shorewall.org>
Community: https://sourceforge.net/p/shorewall/mailman/message/37107049/
SPC: https://sourceforge.net/p/shorewall/mailman/message/36596609/
Homepage: https://shorewall.org


_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to