Reload IPtables

Reload IPtables

[slow_speed]

What is the preferred command to reload the current rules for iptables?  
(Please include Debian environment, if distro-specific.)

Re: Reload IPtables

[David Hajes]

on Debian I flushed all tables including custom tables and used to run 
iptables bash script before I moved to nftables. OpenBSD same strategy - 
flush and reload pf.conf

if that is what you mean by reload.

On 25/06/2021 21:24, slow_speed@att.net wrote:
> What is the preferred command to reload the current rules for 
> iptables? (Please include Debian environment, if distro-specific.)
>

Re: Reload IPtables

[slow_speed]

Thank you.

I do not believe it is something one would use a script for. Rather, 
there should be a way to reload the information into memory without 
having to reboot.


On 6/25/21 4:51 PM, David Hajes wrote:
> on Debian I flushed all tables including custom tables and used to run 
> iptables bash script before I moved to nftables. OpenBSD same strategy 
> - flush and reload pf.conf
>
> if that is what you mean by reload.
>
> On 25/06/2021 21:24, slow_speed@att.net wrote:
>> What is the preferred command to reload the current rules for 
>> iptables? (Please include Debian environment, if distro-specific.)
>>

Re: Reload IPtables

[Stephen Satchell]

Look into iptables-restore(8)

Assuming that you have previously used
"iptables-save >/root/iptables.ipv4" and
"ip6tables-save >/root/iptables.ipv6",

then you can reload the tables using
"iptables-restore </root/iptables.ipv4" and
"ip6tables-restore </root/iptables.ipv6"

Note that a save does not save the state of /proc/sys/net variables 
(like /proc/sys/net/ipv4/ip_forward), and consequently restore doesn't 
change the state of /proc/sys/net variables.

When I have written scripts to handle this sort of stuff, I handle 
/proc/sys/net/ipv4/ip_forward and /proc/sys/net/ipv6/conf/*/forwarding 
myself.  To make a reload as atomic as possible, I first turn off 
forwarding, the issue the two restore commands, then set the /proc 
variables to their saved values.

On 6/25/21 2:30 PM, slow_speed@att.net wrote:
> Thank you.
> 
> I do not believe it is something one would use a script for. Rather, 
> there should be a way to reload the information into memory without 
> having to reboot.
> 
> 
> On 6/25/21 4:51 PM, David Hajes wrote:
>> on Debian I flushed all tables including custom tables and used to run 
>> iptables bash script before I moved to nftables. OpenBSD same strategy 
>> - flush and reload pf.conf
>>
>> if that is what you mean by reload.
>>
>> On 25/06/2021 21:24, slow_speed@att.net wrote:
>>> What is the preferred command to reload the current rules for 
>>> iptables? (Please include Debian environment, if distro-specific.)
>>>
> 

Re: Reload IPtables

[slow_speed]

Interesting.  I did not understand how that one worked.  I thought it 
was for something else.

So if a person had installed iptables-persistent, then 
/etc/iptables/rules.v4 and /etc/iptables/rules.v6 were created.  If I 
understand your usage, one would then run:
iptables-restore </etc/iptables/rules.v4.

Is that correct?


On 6/25/21 6:19 PM, Stephen Satchell wrote:
> Look into iptables-restore(8)
>
> Assuming that you have previously used
> "iptables-save >/root/iptables.ipv4" and
> "ip6tables-save >/root/iptables.ipv6",
>
> then you can reload the tables using
> "iptables-restore </root/iptables.ipv4" and
> "ip6tables-restore </root/iptables.ipv6"
>
> Note that a save does not save the state of /proc/sys/net variables 
> (like /proc/sys/net/ipv4/ip_forward), and consequently restore doesn't 
> change the state of /proc/sys/net variables.
>
> When I have written scripts to handle this sort of stuff, I handle 
> /proc/sys/net/ipv4/ip_forward and /proc/sys/net/ipv6/conf/*/forwarding 
> myself.  To make a reload as atomic as possible, I first turn off 
> forwarding, the issue the two restore commands, then set the /proc 
> variables to their saved values.
>
> On 6/25/21 2:30 PM, slow_speed@att.net wrote:
>> Thank you.
>>
>> I do not believe it is something one would use a script for. Rather, 
>> there should be a way to reload the information into memory without 
>> having to reboot.
>>
>>
>> On 6/25/21 4:51 PM, David Hajes wrote:
>>> on Debian I flushed all tables including custom tables and used to 
>>> run iptables bash script before I moved to nftables. OpenBSD same 
>>> strategy - flush and reload pf.conf
>>>
>>> if that is what you mean by reload.
>>>
>>> On 25/06/2021 21:24, slow_speed@att.net wrote:
>>>> What is the preferred command to reload the current rules for 
>>>> iptables? (Please include Debian environment, if distro-specific.)
>>>>
>>
>

Re: Reload IPtables

[Reindl Harald]

Am 25.06.21 um 23:30 schrieb slow_speed@att.net:
> I do not believe it is something one would use a script for. Rather, 
> there should be a way to reload the information into memory without 
> having to reboot.

why would you ever reboot a linux system for something trivial than 
exchange, reset or realod iptables?

* you have your ruleset
* you have saved it
* just load it

"/usr/sbin/iptables-nft-restore /etc/sysconfig/iptables" or 
"iptables-restore" or "iptables-legacy-restore"

there is no difference doing that at boot or any moment in time

> On 6/25/21 4:51 PM, David Hajes wrote:
>> on Debian I flushed all tables including custom tables and used to run 
>> iptables bash script before I moved to nftables. OpenBSD same strategy 
>> - flush and reload pf.conf
>>
>> if that is what you mean by reload.
>>
>> On 25/06/2021 21:24, slow_speed@att.net wrote:
>>> What is the preferred command to reload the current rules for 
>>> iptables? (Please include Debian environment, if distro-specific.)

Re: Reload IPtables

[slow_speed]

Yes, that was exactly my initial question.  I couldn't agree more.

The issue was knowing the correct command to use force the reload. I 
remain unclear on that if my files are in either /etc/iptables.up.rules 
or /etc/iptables/rules.v4.



On 6/25/21 7:43 PM, Reindl Harald wrote:
>
>
> Am 25.06.21 um 23:30 schrieb slow_speed@att.net:
>> I do not believe it is something one would use a script for. Rather, 
>> there should be a way to reload the information into memory without 
>> having to reboot.
>
> why would you ever reboot a linux system for something trivial than 
> exchange, reset or realod iptables?
>
> * you have your ruleset
> * you have saved it
> * just load it
>
> "/usr/sbin/iptables-nft-restore /etc/sysconfig/iptables" or 
> "iptables-restore" or "iptables-legacy-restore"
>
> there is no difference doing that at boot or any moment in time
>
>> On 6/25/21 4:51 PM, David Hajes wrote:
>>> on Debian I flushed all tables including custom tables and used to 
>>> run iptables bash script before I moved to nftables. OpenBSD same 
>>> strategy - flush and reload pf.conf
>>>
>>> if that is what you mean by reload.
>>>
>>> On 25/06/2021 21:24, slow_speed@att.net wrote:
>>>> What is the preferred command to reload the current rules for 
>>>> iptables? (Please include Debian environment, if distro-specific.)

Re: Reload IPtables

[Reindl Harald]

Am 26.06.21 um 01:47 schrieb slow_speed@att.net:
> Yes, that was exactly my initial question.  I couldn't agree more.
> 
> The issue was knowing the correct command to use force the reload. I 
> remain unclear on that if my files are in either /etc/iptables.up.rules 
> or /etc/iptables/rules.v4.

god or your distribution knows

* mine are generate dby a script
* that script writes to /etc/sysconfig/iptables
* my homegrown "network-up.service" loads them at boot

no need for any shiny network-config files and what not. just pure 
"iptables" and "ip" commands in a "oneshot" systemd unit with a dozen of 
ExecStart (the same as a shell script but with better debugging)

burn everything from the distribution with fire


[root@srv-rhsoft:~]$ cat /etc/systemd/system/network-up.service
##############################################################
#  Device-Naming: /etc/udev/rules.d/70-persistent-net.rules  #
##############################################################

[Unit]
DefaultDependencies=no
RefuseManualStop=yes
Description=Network
PartOf=basic.target
PartOf=network-online.target
Before=crond.service timers.target vnstat.service

After=sys-subsystem-net-devices-wan.device
Wants=sys-subsystem-net-devices-wan.device

After=sys-subsystem-net-devices-lan\x2dguest.device
Wants=sys-subsystem-net-devices-lan\x2dguest.device
After=sys-subsystem-net-devices-lan\x2dspare1.device
Wants=sys-subsystem-net-devices-lan\x2dspare1.device
After=sys-subsystem-net-devices-lan\x2dspare2.device
Wants=sys-subsystem-net-devices-lan\x2dspare2.device
After=sys-subsystem-net-devices-lan\x2dtv.device
Wants=sys-subsystem-net-devices-lan\x2dtv.device
After=sys-subsystem-net-devices-poe\x2dphone.device
Wants=sys-subsystem-net-devices-poe\x2dphone.device
After=sys-subsystem-net-devices-poe\x2dspare.device
Wants=sys-subsystem-net-devices-poe\x2dspare.device

[Service]
Type=oneshot
RemainAfterExit=yes
SuccessExitStatus=80
TimeoutStartSec=60

ExecStart=/usr/sbin/ipset -file /etc/sysconfig/ipset restore
ExecStart=/usr/sbin/iptables-nft-restore /etc/sysconfig/iptables

ExecStart=-/usr/sbin/ip link add name br-wan type bridge
ExecStart=-/usr/sbin/ip link set dev wan master br-wan multicast off 
allmulticast off up
ExecStart=-/usr/sbin/ip link set dev vmnet1 master br-wan multicast off 
allmulticast off up
ExecStart=-/usr/sbin/ip addr flush vmnet1

ExecStart=-/usr/bin/systemctl start vpn.service

ExecStart=-/usr/sbin/ip link add name br-lan type bridge
ExecStart=-/usr/sbin/ip link set dev br-lan up
ExecStart=-/usr/sbin/ip a add 192.168.2.2/255.255.255.0 broadcast 
192.168.2.255 dev br-lan
ExecStart=-/usr/sbin/ip link set dev lan-spare1 master br-lan up
ExecStart=-/usr/sbin/ip link set dev lan-spare2 master br-lan up
ExecStart=-/usr/sbin/ip link set dev lan-tv master br-lan up
ExecStart=-/usr/sbin/ip link set dev poe-spare master br-lan up
ExecStart=-/usr/sbin/ip link set dev poe-phone master br-lan multicast 
off allmulticast off up

ExecStart=-/usr/sbin/ip link add name br-guest type bridge
ExecStart=-/usr/sbin/ip link set dev br-guest multicast off allmulticast 
off up
ExecStart=-/usr/sbin/ip a add 192.168.10.1/255.255.255.0 broadcast 
192.168.10.255 dev br-guest
ExecStart=-/usr/sbin/ip link set dev lan-guest master br-guest multicast 
off allmulticast off up

ExecStart=-/usr/sbin/ip route add 172.17.0.0/24 via 192.168.196.5 dev vmnet8

ExecStart=-/usr/bin/systemctl start network-wan-dhcp.service

ExecStart=-/usr/sbin/sysctl -q --load=/etc/sysctl*.conf

ExecStart=-/usr/sbin/tc qdisc add dev wan root handle 1 hfsc default 1
ExecStart=-/usr/sbin/tc class add dev wan parent 1: classid 1:1 hfsc sc 
rate 54Mbit ul rate 54Mbit
ExecStart=-/usr/sbin/tc qdisc add dev wan parent 1:1 handle 11: fq_codel

[Install]
WantedBy=basic.target
[root@srv-rhsoft:~]$

> On 6/25/21 7:43 PM, Reindl Harald wrote:
>>
>>
>> Am 25.06.21 um 23:30 schrieb slow_speed@att.net:
>>> I do not believe it is something one would use a script for. Rather, 
>>> there should be a way to reload the information into memory without 
>>> having to reboot.
>>
>> why would you ever reboot a linux system for something trivial than 
>> exchange, reset or realod iptables?
>>
>> * you have your ruleset
>> * you have saved it
>> * just load it
>>
>> "/usr/sbin/iptables-nft-restore /etc/sysconfig/iptables" or 
>> "iptables-restore" or "iptables-legacy-restore"
>>
>> there is no difference doing that at boot or any moment in time
>>
>>> On 6/25/21 4:51 PM, David Hajes wrote:
>>>> on Debian I flushed all tables including custom tables and used to 
>>>> run iptables bash script before I moved to nftables. OpenBSD same 
>>>> strategy - flush and reload pf.conf
>>>>
>>>> if that is what you mean by reload.
>>>>
>>>> On 25/06/2021 21:24, slow_speed@att.net wrote:
>>>>> What is the preferred command to reload the current rules for 
>>>>> iptables? (Please include Debian environment, if distro-specific.)

Re: Reload IPtables

[David Hajes]

now you know why I use own scripts that are portable to any 
Linux/OpenBSD/BSD-like machine

I have never used iptable-save/restore in my life...it doesn't handle 
variables like "ip_forward" for example and there is more to setup.

why would you reboot machine just because you need reload firewall?

it seems to me that you need to learn basics of firewalling and Linux 
management.

On 26/06/2021 01:47, slow_speed@att.net wrote:
> Yes, that was exactly my initial question.  I couldn't agree more.
>
> The issue was knowing the correct command to use force the reload. I 
> remain unclear on that if my files are in either 
> /etc/iptables.up.rules or /etc/iptables/rules.v4.
>
>
>
> On 6/25/21 7:43 PM, Reindl Harald wrote:
>>
>>
>> Am 25.06.21 um 23:30 schrieb slow_speed@att.net:
>>> I do not believe it is something one would use a script for. Rather, 
>>> there should be a way to reload the information into memory without 
>>> having to reboot.
>>
>> why would you ever reboot a linux system for something trivial than 
>> exchange, reset or realod iptables?
>>
>> * you have your ruleset
>> * you have saved it
>> * just load it
>>
>> "/usr/sbin/iptables-nft-restore /etc/sysconfig/iptables" or 
>> "iptables-restore" or "iptables-legacy-restore"
>>
>> there is no difference doing that at boot or any moment in time
>>
>>> On 6/25/21 4:51 PM, David Hajes wrote:
>>>> on Debian I flushed all tables including custom tables and used to 
>>>> run iptables bash script before I moved to nftables. OpenBSD same 
>>>> strategy - flush and reload pf.conf
>>>>
>>>> if that is what you mean by reload.
>>>>
>>>> On 25/06/2021 21:24, slow_speed@att.net wrote:
>>>>> What is the preferred command to reload the current rules for 
>>>>> iptables? (Please include Debian environment, if distro-specific.)
>
>

Re: Reload IPtables

[Reindl Harald]

Am 26.06.21 um 09:19 schrieb David Hajes:
> now you know why I use own scripts that are portable to any 
> Linux/OpenBSD/BSD-like machine

sounds like a terrible mess with a ton of conditions which only works 
with a simple ruleset

> I have never used iptable-save/restore in my life...it doesn't handle 
> variables like "ip_forward" for example and there is more to setup.

it's not it's job to handle sysctl

that belongs into a different file and running the iptables-script at 
boot is a terrible idea because it's slow an non-atomic

the only time when you should run a complex script is when you change 
something and not at boot time where you simply restore the last state

/usr/sbin/ipset -file /etc/sysconfig/ipset restore
/usr/sbin/iptables-nft-restore /etc/sysconfig/iptables
/usr/sbin/sysctl -q --load=/etc/sysctl*.conf

that way first all rules are loaded atomic and *then* "ip_forward" and 
friends are set to avoid a leak at boot

> why would you reboot machine just because you need reload firewall?
> 
> it seems to me that you need to learn basics of firewalling and Linux 
> management.
> 
> On 26/06/2021 01:47, slow_speed@att.net wrote:
>> Yes, that was exactly my initial question.  I couldn't agree more.
>>
>> The issue was knowing the correct command to use force the reload. I 
>> remain unclear on that if my files are in either 
>> /etc/iptables.up.rules or /etc/iptables/rules.v4.
>>
>>
>>
>> On 6/25/21 7:43 PM, Reindl Harald wrote:
>>>
>>>
>>> Am 25.06.21 um 23:30 schrieb slow_speed@att.net:
>>>> I do not believe it is something one would use a script for. Rather, 
>>>> there should be a way to reload the information into memory without 
>>>> having to reboot.
>>>
>>> why would you ever reboot a linux system for something trivial than 
>>> exchange, reset or realod iptables?
>>>
>>> * you have your ruleset
>>> * you have saved it
>>> * just load it
>>>
>>> "/usr/sbin/iptables-nft-restore /etc/sysconfig/iptables" or 
>>> "iptables-restore" or "iptables-legacy-restore"
>>>
>>> there is no difference doing that at boot or any moment in time
>>>
>>>> On 6/25/21 4:51 PM, David Hajes wrote:
>>>>> on Debian I flushed all tables including custom tables and used to 
>>>>> run iptables bash script before I moved to nftables. OpenBSD same 
>>>>> strategy - flush and reload pf.conf
>>>>>
>>>>> if that is what you mean by reload.
>>>>>
>>>>> On 25/06/2021 21:24, slow_speed@att.net wrote:
>>>>>> What is the preferred command to reload the current rules for 
>>>>>> iptables? (Please include Debian environment, if distro-specific.)

Re: Reload IPtables

[David Hajes]

> sounds like a terrible mess with a ton of conditions which only works 
> with a simple ruleset

how many people do you know that use Linux with 10k lines in iptables?

slowest thing about loading iptables script was dealing with fail2ban 
that takes ages to load all banned IPs.

if guy asks how to reload properly ruleset - I doubt he has got any 
complex filtering on his machine ;-)

>
> it's not it's job to handle sysctl
>
> that belongs into a different file and running the iptables-script at 
> boot is a terrible idea because it's slow an non-atomic
>
> the only time when you should run a complex script is when you change 
> something and not at boot time where you simply restore the last state
>
> /usr/sbin/ipset -file /etc/sysconfig/ipset restore
> /usr/sbin/iptables-nft-restore /etc/sysconfig/iptables
> /usr/sbin/sysctl -q --load=/etc/sysctl*.conf
>
> that way first all rules are loaded atomic and *then* "ip_forward" and 
> friends are set to avoid a leak at boot

it may be good for you pro administrators with complex 
configurations...I have all in one file and do not need to bother about 
1ms lost during reload nor seeking 10 different config files for simple 
tasks and wasting hours by config. I like easy life.

My guess was that guy who asked doesn't have anything special and simple 
script resolves is terrible life trauma ;-)

Otherwise, he wouldn't ask such a question that is simple RTFM or UTFG ;-)

>
>> why would you reboot machine just because you need reload firewall?
>>
>> it seems to me that you need to learn basics of firewalling and Linux 
>> management.
>>
>> On 26/06/2021 01:47, slow_speed@att.net wrote:
>>> Yes, that was exactly my initial question.  I couldn't agree more.
>>>
>>> The issue was knowing the correct command to use force the reload. I 
>>> remain unclear on that if my files are in either 
>>> /etc/iptables.up.rules or /etc/iptables/rules.v4.
>>>
>>>
>>>
>>> On 6/25/21 7:43 PM, Reindl Harald wrote:
>>>>
>>>>
>>>> Am 25.06.21 um 23:30 schrieb slow_speed@att.net:
>>>>> I do not believe it is something one would use a script for. 
>>>>> Rather, there should be a way to reload the information into 
>>>>> memory without having to reboot.
>>>>
>>>> why would you ever reboot a linux system for something trivial than 
>>>> exchange, reset or realod iptables?
>>>>
>>>> * you have your ruleset
>>>> * you have saved it
>>>> * just load it
>>>>
>>>> "/usr/sbin/iptables-nft-restore /etc/sysconfig/iptables" or 
>>>> "iptables-restore" or "iptables-legacy-restore"
>>>>
>>>> there is no difference doing that at boot or any moment in time
>>>>
>>>>> On 6/25/21 4:51 PM, David Hajes wrote:
>>>>>> on Debian I flushed all tables including custom tables and used 
>>>>>> to run iptables bash script before I moved to nftables. OpenBSD 
>>>>>> same strategy - flush and reload pf.conf
>>>>>>
>>>>>> if that is what you mean by reload.
>>>>>>
>>>>>> On 25/06/2021 21:24, slow_speed@att.net wrote:
>>>>>>> What is the preferred command to reload the current rules for 
>>>>>>> iptables? (Please include Debian environment, if distro-specific.)

Re: Reload IPtables

[Reindl Harald]

Am 26.06.21 um 12:27 schrieb David Hajes:
>> sounds like a terrible mess with a ton of conditions which only works 
>> with a simple ruleset
> 
> how many people do you know that use Linux with 10k lines in iptables?

but why make it complex with abstraction layers when the ruleset is that 
simple

> slowest thing about loading iptables script was dealing with fail2ban 
> that takes ages to load all banned IPs.

that's why ipset exists which don't care much if there is 1 or 1 million 
entries

> if guy asks how to reload properly ruleset - I doubt he has got any 
> complex filtering on his machine ;-)

that may be true

>> it's not it's job to handle sysctl
>>
>> that belongs into a different file and running the iptables-script at 
>> boot is a terrible idea because it's slow an non-atomic
>>
>> the only time when you should run a complex script is when you change 
>> something and not at boot time where you simply restore the last state
>>
>> /usr/sbin/ipset -file /etc/sysconfig/ipset restore
>> /usr/sbin/iptables-nft-restore /etc/sysconfig/iptables
>> /usr/sbin/sysctl -q --load=/etc/sysctl*.conf
>>
>> that way first all rules are loaded atomic and *then* "ip_forward" and 
>> friends are set to avoid a leak at boot
> 
> it may be good for you pro administrators with complex 
> configurations...I have all in one file and do not need to bother about 
> 1ms lost during reload nor seeking 10 different config files for simple 
> tasks and wasting hours by config. I like easy life.

mixing things together which don't belong together like iptables and 
sysctl is the opposite of simple as well as running a ton of commands at 
boot where it should be a oneliner is also the opposite

to be honest that sounds more like "i didn't know about save/restore as 
i wrote that stuff"

> My guess was that guy who asked doesn't have anything special and simple 
> script resolves is terrible life trauma ;-)
> 
> Otherwise, he wouldn't ask such a question that is simple RTFM or UTFG ;-)

that may be true

>>> why would you reboot machine just because you need reload firewall?
>>>
>>> it seems to me that you need to learn basics of firewalling and Linux 
>>> management.
>>>
>>> On 26/06/2021 01:47, slow_speed@att.net wrote:
>>>> Yes, that was exactly my initial question.  I couldn't agree more.
>>>>
>>>> The issue was knowing the correct command to use force the reload. I 
>>>> remain unclear on that if my files are in either 
>>>> /etc/iptables.up.rules or /etc/iptables/rules.v4.
>>>>
>>>>
>>>>
>>>> On 6/25/21 7:43 PM, Reindl Harald wrote:
>>>>>
>>>>>
>>>>> Am 25.06.21 um 23:30 schrieb slow_speed@att.net:
>>>>>> I do not believe it is something one would use a script for. 
>>>>>> Rather, there should be a way to reload the information into 
>>>>>> memory without having to reboot.
>>>>>
>>>>> why would you ever reboot a linux system for something trivial than 
>>>>> exchange, reset or realod iptables?
>>>>>
>>>>> * you have your ruleset
>>>>> * you have saved it
>>>>> * just load it
>>>>>
>>>>> "/usr/sbin/iptables-nft-restore /etc/sysconfig/iptables" or 
>>>>> "iptables-restore" or "iptables-legacy-restore"
>>>>>
>>>>> there is no difference doing that at boot or any moment in time
>>>>>
>>>>>> On 6/25/21 4:51 PM, David Hajes wrote:
>>>>>>> on Debian I flushed all tables including custom tables and used 
>>>>>>> to run iptables bash script before I moved to nftables. OpenBSD 
>>>>>>> same strategy - flush and reload pf.conf
>>>>>>>
>>>>>>> if that is what you mean by reload.
>>>>>>>
>>>>>>> On 25/06/2021 21:24, slow_speed@att.net wrote:
>>>>>>>> What is the preferred command to reload the current rules for 
>>>>>>>> iptables? (Please include Debian environment, if distro-specific.)

Re: Reload IPtables

[David Hajes]

> that's why ipset exists which don't care much if there is 1 or 1 
> million entries
>
fail2ban use(d) sqlite/ipset...it is issue with fail2ban, not 
iptables+ipset...it didn't improve with nftables either.

I used to use a kludge where I manually loaded persistently banned IPs 
into ipset table...it loaded 100x faster than fail2ban native function


>> if guy asks how to reload properly ruleset - I doubt he has got any 
>> complex filtering on his machine ;-)
>
> that may be true
>
>>> it's not it's job to handle sysctl
>>>
>>> that belongs into a different file and running the iptables-script 
>>> at boot is a terrible idea because it's slow an non-atomic
>>>
>>> the only time when you should run a complex script is when you 
>>> change something and not at boot time where you simply restore the 
>>> last state
>>>
>>> /usr/sbin/ipset -file /etc/sysconfig/ipset restore
>>> /usr/sbin/iptables-nft-restore /etc/sysconfig/iptables
>>> /usr/sbin/sysctl -q --load=/etc/sysctl*.conf
>>>
>>> that way first all rules are loaded atomic and *then* "ip_forward" 
>>> and friends are set to avoid a leak at boot
>>
>> it may be good for you pro administrators with complex 
>> configurations...I have all in one file and do not need to bother 
>> about 1ms lost during reload nor seeking 10 different config files 
>> for simple tasks and wasting hours by config. I like easy life.
>
> mixing things together which don't belong together like iptables and 
> sysctl is the opposite of simple as well as running a ton of commands 
> at boot where it should be a oneliner is also the opposite
>
> to be honest that sounds more like "i didn't know about save/restore 
> as i wrote that stuff"
>
>> My guess was that guy who asked doesn't have anything special and 
>> simple script resolves is terrible life trauma ;-)
>>
>> Otherwise, he wouldn't ask such a question that is simple RTFM or 
>> UTFG ;-)
>
> that may be true
>
>>>> why would you reboot machine just because you need reload firewall?
>>>>
>>>> it seems to me that you need to learn basics of firewalling and 
>>>> Linux management.
>>>>
>>>> On 26/06/2021 01:47, slow_speed@att.net wrote:
>>>>> Yes, that was exactly my initial question.  I couldn't agree more.
>>>>>
>>>>> The issue was knowing the correct command to use force the reload. 
>>>>> I remain unclear on that if my files are in either 
>>>>> /etc/iptables.up.rules or /etc/iptables/rules.v4.
>>>>>
>>>>>
>>>>>
>>>>> On 6/25/21 7:43 PM, Reindl Harald wrote:
>>>>>>
>>>>>>
>>>>>> Am 25.06.21 um 23:30 schrieb slow_speed@att.net:
>>>>>>> I do not believe it is something one would use a script for. 
>>>>>>> Rather, there should be a way to reload the information into 
>>>>>>> memory without having to reboot.
>>>>>>
>>>>>> why would you ever reboot a linux system for something trivial 
>>>>>> than exchange, reset or realod iptables?
>>>>>>
>>>>>> * you have your ruleset
>>>>>> * you have saved it
>>>>>> * just load it
>>>>>>
>>>>>> "/usr/sbin/iptables-nft-restore /etc/sysconfig/iptables" or 
>>>>>> "iptables-restore" or "iptables-legacy-restore"
>>>>>>
>>>>>> there is no difference doing that at boot or any moment in time
>>>>>>
>>>>>>> On 6/25/21 4:51 PM, David Hajes wrote:
>>>>>>>> on Debian I flushed all tables including custom tables and used 
>>>>>>>> to run iptables bash script before I moved to nftables. OpenBSD 
>>>>>>>> same strategy - flush and reload pf.conf
>>>>>>>>
>>>>>>>> if that is what you mean by reload.
>>>>>>>>
>>>>>>>> On 25/06/2021 21:24, slow_speed@att.net wrote:
>>>>>>>>> What is the preferred command to reload the current rules for 
>>>>>>>>> iptables? (Please include Debian environment, if 
>>>>>>>>> distro-specific.)

Re: Reload IPtables

[slow_speed]

A most fundamental part of learning is asking questions.  That is what 
I'm doing here.

And I'd still like some verification of the exact command to reload the 
tables.

On 6/26/21 3:19 AM, David Hajes wrote:
> it seems to me that you need to learn basics of firewalling and Linux 
> management. 

Re: Reload IPtables

[G.W. Haywood]

[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]

Hi there,

On Sun, 27 Jun 2021, slow_speed@att.net wrote:
> On 6/26/21 3:19 AM, David Hajes wrote:
> 
>> it seems to me that you need to learn basics of firewalling and Linux 
>> management. 
> 
> A most fundamental part of learning is asking questions.  That is what I'm 
> doing here.

Mailing lists are not usually intended to replace doing your homework.

People tire of answering questions which wouldn't need to be asked if
the questioner had dome some modest amount of reading.  There are
numerous documents, not least those already on your computer, and many
on the netfilter Website

https://www.netfilter.org/documentation/

the study of which would greatly enhance your understanding without
causing friction on this list.

In the case of a firewall (not that to use iptables is necessarily to
implement a firewall, but in the case of a firewall) it's a matter of
"drink deep, or taste not the Pierian spring" - because if you get it
wrong with a firewall it might not be obvious and you might well live
to rue the day.

> And I'd still like some verification of the exact command to reload the 
> tables.

There isn't an "exact command to reload the iptables".  Even supposing
there was some exact command which answers whatever question you're
really asking, to get to it you'd need to put a great deal more work
into the question.  The packet filtering susbsystem is a very complex
beast and there are numerous tools available to help you work with it.
The iptables command is one of them.  Like many commands it has what's
known as a "man page"; we say that as a kind of shorthand for starting
a shell and at the shell prompt then (in the case of iptables) running
the command

man iptables

which I urge you to try.  The man pages have a standard format and you
should make yourself familiar with it and be familiar with using them.
Although they're called pages, in reality each page can be a document
many pages (screens, whatever) in length.  When you're familiar with
them you'll have a wealth of information at your fingertips which will
most often answer your questions in much less time than starting some
thread on a mailing list.

-- 

73,
Ged.

Re: Reload IPtables

[Kerin Millar]

On Fri, 25 Jun 2021 19:47:02 -0400
slow_speed@att.net wrote:

> Yes, that was exactly my initial question.  I couldn't agree more.
> 
> The issue was knowing the correct command to use force the reload. I 
> remain unclear on that if my files are in either /etc/iptables.up.rules 
> or /etc/iptables/rules.v4.

Debian offers an iptables-persistent package which, if installed, will provide a plugin for their netfilter-persistent package. In turn, that implements a pseudo-service that is capable of automatically loading iptables rules from "/etc/iptables/rules.v4" upon being started, and saving them there upon being stopped. It does so by executing iptables-restore(8) and iptables-save(8) behind the scenes and the decision to use this particular location is an arbitrary one made by the Debian maintainers. As for "/etc/iptables.up.rules", it has no significance beyond serving as one example of how to manually deal with ruleset persistence, as far as the author of the https://wiki.debian.org/iptables article is concerned.

So, if you needed to manually (re)load an iptables ruleset that had previously been saved through the use of the iptables-persistent plugin, you might run `iptables-restore /etc/iptables/rules.v4` but it would probably be wiser to run `netfilter-persistent start` instead. For further information, refer to the netfilter-persistent(8) man page. On the other hand, should you choose not to use iptables-persistent, the decision of where exactly to save rulesets is yours to make. If in doubt, observe the conventions chosen by your distribution.

-- 
Kerin Millar

Re: Reload IPtables

[Stephen Satchell]

On 6/27/21 7:56 AM, slow_speed@att.net wrote:
> A most fundamental part of learning is asking questions.  That is what 
> I'm doing here.
> 
> And I'd still like some verification of the exact command to reload the 
> tables.

iptables-reload
ip6tables-reload

I explained about the usage of these two programs.  The man pages 
describe all the options.

 From my previous e-mail:

> Assuming that you have previously used
> "iptables-save >/root/iptables.ipv4" and
> "ip6tables-save >/root/iptables.ipv6",
> 
> then you can reload the tables using
> "iptables-restore </root/iptables.ipv4" and
> "ip6tables-restore </root/iptables.ipv6"
> 
> Note that a save does not save the state of /proc/sys/net variables (like /proc/sys/net/ipv4/ip_forward), and consequently restore doesn't change the state of /proc/sys/net variables.
> 
> When I have written scripts to handle this sort of stuff, I handle /proc/sys/net/ipv4/ip_forward and /proc/sys/net/ipv6/conf/*/forwarding myself.  To make a reload as atomic as possible, I first turn off forwarding, the issue the two restore commands, then set the /proc variables to their saved values.

Re: Reload IPtables

[slow_speed]

Thank you for that very good explanation.

As it turns out, I am learning two ways at once.  One is my desktop 
computer running Debian 10 which used nftables (and I believe 
nftables-persistent is built-in to the nftables mechanism).  The other 
is a little Raspian server which is based on Debian 10, but does not use 
nftables.

In the second case, one must reload iptables when changes are made to 
it.  If I correctly understand, one must use sudo iptables -F, followed 
by sudo iptables-restore < /etc/iptables.up.rules (or wherever they 
are).  Doesn't it need the little left arrow/less-than sign?  Does that 
sound correct?


On 6/27/21 2:11 PM, Kerin Millar wrote:
> On Fri, 25 Jun 2021 19:47:02 -0400
> slow_speed@att.net wrote:
>
>> Yes, that was exactly my initial question.  I couldn't agree more.
>>
>> The issue was knowing the correct command to use force the reload. I
>> remain unclear on that if my files are in either /etc/iptables.up.rules
>> or /etc/iptables/rules.v4.
> Debian offers an iptables-persistent package which, if installed, will provide a plugin for their netfilter-persistent package. In turn, that implements a pseudo-service that is capable of automatically loading iptables rules from "/etc/iptables/rules.v4" upon being started, and saving them there upon being stopped. It does so by executing iptables-restore(8) and iptables-save(8) behind the scenes and the decision to use this particular location is an arbitrary one made by the Debian maintainers. As for "/etc/iptables.up.rules", it has no significance beyond serving as one example of how to manually deal with ruleset persistence, as far as the author of the https://wiki.debian.org/iptables article is concerned.
>
> So, if you needed to manually (re)load an iptables ruleset that had previously been saved through the use of the iptables-persistent plugin, you might run `iptables-restore /etc/iptables/rules.v4` but it would probably be wiser to run `netfilter-persistent start` instead. For further information, refer to the netfilter-persistent(8) man page. On the other hand, should you choose not to use iptables-persistent, the decision of where exactly to save rulesets is yours to make. If in doubt, observe the conventions chosen by your distribution.
>

Re: Reload IPtables

[Reindl Harald]

Am 27.06.21 um 20:32 schrieb slow_speed@att.net:
> As it turns out, I am learning two ways at once.  One is my desktop 
> computer running Debian 10 which used nftables (and I believe 
> nftables-persistent is built-in to the nftables mechanism).  The other 
> is a little Raspian server which is based on Debian 10, but does not use 
> nftables.

it's very distribution specific and that's why this is likely the wrong 
mailing list

> In the second case, one must reload iptables when changes are made to 
> it.  If I correctly understand, one must use sudo iptables -F

why do you think you need a manual flush?

> followed 
> by sudo iptables-restore < /etc/iptables.up.rules (or wherever they 
> are).  Doesn't it need the little left arrow/less-than sign?  Does that 
> sound correct?
why don't you at least show at the help output?

how does adding "<" make sense when the last param is already a file path?

[root@srv-rhsoft:~]$ iptables-restore --help
Usage: iptables-restore [-c] [-v] [-V] [-t] [-h] [-n] [-T table] [-M 
command] [-4] [-6] [file]
            [ --counters ]
            [ --verbose ]
            [ --version]
            [ --test ]
            [ --help ]
            [ --noflush ]
            [ --table=<TABLE> ]
            [ --modprobe=<command> ]
            [ --ipv4 ]

Re: Reload IPtables

[Kerin Millar]

On Sun, 27 Jun 2021 14:32:39 -0400
slow_speed@att.net wrote:

> Thank you for that very good explanation.
> 
> As it turns out, I am learning two ways at once.  One is my desktop 
> computer running Debian 10 which used nftables (and I believe 
> nftables-persistent is built-in to the nftables mechanism).  The other 
> is a little Raspian server which is based on Debian 10, but does not use 
> nftables.
> 
> In the second case, one must reload iptables when changes are made to 
> it.  If I correctly understand, one must use sudo iptables -F, followed 
> by sudo iptables-restore < /etc/iptables.up.rules (or wherever they 
> are).  Doesn't it need the little left arrow/less-than sign?  Does that 
> sound correct?

Concerning wherever they may be, they would be at "/etc/iptables.rules.v4" in the event that you are using iptables-persistent.

In any case, no, I would not consider this approach to be correct. Running `iptables -F` will empty the chains in the filter table. Not only would it fall short of 'resetting' the entire ruleset, you would be rendering the overall procedure non-atomic by unnecessarily splitting it into two distinct steps. Depending on your default chain policies, you could leave yourself temporarily wide open or, say, lock yourself out of a remote system. That's before even getting to the point of validating the ruleset that you intend to load. Just go straight to invoking iptables-restore (or netfilter-persistent). As long as the ruleset is valid, it will be applied in full, atomically. Otherwise, an error will be displayed and nothing will change. There is no in-between, which is as it should be. In short: my advice remains as conveyed by my previous post.

Use of shell redirection is optional in this case but I would caution against making it a habit in conjunction with the use of sudo. The shell will execute sudo which, in turn, will execute iptables-restore with root privileges. However, that very same shell - which, presumably, wasn't running as root to begin with - will process the redirection operator and attempt to open the given file. Provided that the file is readable by the shell's user, this poses no problem. However, should the file's permissions be restricted to the extent that only the root user can read the file, failure will ensue. By contrast, `sudo iptables-restore /etc/iptables.up.rules` is immune because the responsibility for opening the file is delegated to iptables-restore itself.

-- 
Kerin Millar

Re: Reload IPtables

[Kerin Millar]

On Sun, 27 Jun 2021 20:07:52 +0100
Kerin Millar <kfm@plushkava.net> wrote:

Self-correction follows ...

> On Sun, 27 Jun 2021 14:32:39 -0400
> slow_speed@att.net wrote:
> 
> > Thank you for that very good explanation.
> > 
> > As it turns out, I am learning two ways at once.  One is my desktop 
> > computer running Debian 10 which used nftables (and I believe 
> > nftables-persistent is built-in to the nftables mechanism).  The other 
> > is a little Raspian server which is based on Debian 10, but does not use 
> > nftables.
> > 
> > In the second case, one must reload iptables when changes are made to 
> > it.  If I correctly understand, one must use sudo iptables -F, followed 
> > by sudo iptables-restore < /etc/iptables.up.rules (or wherever they 
> > are).  Doesn't it need the little left arrow/less-than sign?  Does that 
> > sound correct?
> 
> Concerning wherever they may be, they would be at "/etc/iptables.rules.v4" in the event that you are using iptables-persistent.

Of course, I meant to write "/etc/iptables/rules.v4" here.

-- 
Kerin Millar

Re: Reload IPtables

[Stephen Satchell]

On 6/27/21 11:32 AM, slow_speed@att.net wrote:
> As it turns out, I am learning two ways at once.  One is my desktop 
> computer running Debian 10 which used nftables (and I believe 
> nftables-persistent is built-in to the nftables mechanism).  The other 
> is a little Raspian server which is based on Debian 10, but does not use 
> nftables.

I've only got started with nftables, which is why I bought the latest 
edition of Linux Firewalls.  In particular, I wanted to duplicate 
reverse packet filtering, but in both IPv4 and IPv6.  So I don't know 
the toolset for nft yet.

> In the second case, one must reload iptables when changes are made to 
> it.  If I correctly understand, one must use sudo iptables -F, followed 
> by sudo iptables-restore < /etc/iptables.up.rules (or wherever they 
> are).  Doesn't it need the little left arrow/less-than sign?  Does that 
> sound correct?

Yes.  What you are doing with iptables-restore (and ip6tables-restore) 
is presenting the contents of a file originally created by 
ip[6]tables-save to stdin of the -restore programs.

By the way, if I'm reading the man page correctly  ip[6]tables-restore 
does the -F for you, unless you tell it not to.  You can also restore 
only a single table from the collected rules.  Details on the man page.

Re: Reload IPtables

[Stephen Satchell]

On 6/27/21 12:07 PM, Kerin Millar wrote:
> Use of shell redirection is optional in this case but I would caution
> against making it a habit in conjunction with the use of sudo.

I believe your statement is not distribution-safe.  Red Hat's 
implementation of ip[6]tables-restore does not implement reading a file. 
  Ubuntu's implementation of ip[6]tables-restore does.

This observation is backed up by viewing "iptables-restore -h".

That said, I suspect that Debian would use substantially the same 
version of iptables-restore that Ubuntu does, so your observation would 
be applicable.

(I spend two decades in the Red Hat universe.  Then CentOS happened. 
Moving all my servers to Ubuntu server edition.)

Re: Reload IPtables

[Kerin Millar]

On Sun, 27 Jun 2021 12:56:18 -0700
Stephen Satchell <list@satchell.net> wrote:

> On 6/27/21 12:07 PM, Kerin Millar wrote:
> > Use of shell redirection is optional in this case but I would caution
> > against making it a habit in conjunction with the use of sudo.
> 
> I believe your statement is not distribution-safe.  Red Hat's 
> implementation of ip[6]tables-restore does not implement reading a file. 
>   Ubuntu's implementation of ip[6]tables-restore does.
> 
> This observation is backed up by viewing "iptables-restore -h".
> 
> That said, I suspect that Debian would use substantially the same 
> version of iptables-restore that Ubuntu does, so your observation would 
> be applicable.

Debian 10 was mentioned but yes, it has not always been possible to supply a pathname as an argument. For those with an older userspace, the problem can thus be avoided by simply running `sudo -i` to obtain an interactive root shell or by running `sudo sh -c 'iptables-restore < my.rules'`, among other methods.

-- 
Kerin Millar

Re: Reload IPtables

[Reindl Harald]

Am 27.06.21 um 22:12 schrieb Kerin Millar:
> On Sun, 27 Jun 2021 12:56:18 -0700
> Stephen Satchell <list@satchell.net> wrote:
> 
>> On 6/27/21 12:07 PM, Kerin Millar wrote:
>>> Use of shell redirection is optional in this case but I would caution
>>> against making it a habit in conjunction with the use of sudo.
>>
>> I believe your statement is not distribution-safe.  Red Hat's
>> implementation of ip[6]tables-restore does not implement reading a file.
>>    Ubuntu's implementation of ip[6]tables-restore does.
>>
>> This observation is backed up by viewing "iptables-restore -h".
>>
>> That said, I suspect that Debian would use substantially the same
>> version of iptables-restore that Ubuntu does, so your observation would
>> be applicable.
> 
> Debian 10 was mentioned but yes, it has not always been possible to supply a pathname as an argument. For those with an older userspace, the problem can thus be avoided by simply running `sudo -i` to obtain an interactive root shell or by running `sudo sh -c 'iptables-restore < my.rules'`, among other methods

the real solution is get rid of that stupid "sudo" in front of every 
single line and use a root shell when you use administrative commands

especially when the final goal is writing scripts
that's why we have tabs for different sessions these days

Re: Reload IPtables

[slow_speed]

On 6/27/21 2:57 PM, Reindl Harald wrote:
>
> it's very distribution specific and that's why this is likely the 
> wrong mailing list
Yes, I understand the distribution issue; I was just pointing that out.  
However, netfilter@vger.kernel.org appears to be the end-all and be-all 
of netfilter issues.  Thus, one should address this list.

Further, we should not learn just for one distro.  That would be a huge 
mistake.

> why do you think you need a manual flush? 

Because I do not have the experience regarding the internal workings of 
iptables/nftables in this regard.

It is very simply; does one need to flush before reloading or not?

Re: Reload IPtables

[Reindl Harald]

Am 27.06.21 um 22:57 schrieb slow_speed@att.net:
> 
> On 6/27/21 2:57 PM, Reindl Harald wrote:
>>
>> it's very distribution specific and that's why this is likely the 
>> wrong mailing list
> Yes, I understand the distribution issue; I was just pointing that out. 
> However, netfilter@vger.kernel.org appears to be the end-all and be-all 
> of netfilter issues.  Thus, one should address this list.
> 
> Further, we should not learn just for one distro.  That would be a huge 
> mistake.

exactly, but which file is where holding your config is distribution 
specific unless you ignore all that stuff and start standing on your own 
feet

>> why do you think you need a manual flush? 
> 
> Because I do not have the experience regarding the internal workings of 
> iptables/nftables in this regard.
> 
> It is very simply; does one need to flush before reloading or not?

no and the word "reload" is simply wrong
you *load* a saved rulestate as you do at boot time

Re: Reload IPtables

[Alessandro Vesely, Alessandro Vesely]

On Sat 26/Jun/2021 12:43:45 +0200 Reindl Harald wrote:
>>>
>>> /usr/sbin/ipset -file /etc/sysconfig/ipset restore
>>> /usr/sbin/iptables-nft-restore /etc/sysconfig/iptables
>>> /usr/sbin/sysctl -q --load=/etc/sysctl*.conf
>>>
>>> that way first all rules are loaded atomic and *then* "ip_forward" and 
>>> friends are set to avoid a leak at boot
>>
>> it may be good for you pro administrators with complex configurations...I 
>> have all in one file and do not need to bother about 1ms lost during reload 
>> nor seeking 10 different config files for simple tasks and wasting hours by 
>> config. I like easy life.
> 
> mixing things together which don't belong together like iptables and sysctl is 
> the opposite of simple as well as running a ton of commands at boot where it 
> should be a oneliner is also the opposite


I'm with David here.  Besides sysctl and ipset, there are lots of ip commands, 
modprobe's, vconfig, and a couple of home-brewed daemons (ipqbdb).  A soundly 
commented script captures the logic of the network and can be maintained with 
more coherence than raw commands accumulated along the way.  The only drawback 
is that most changes, for example punching a hole in the firewall, have to be 
applied twice, in the boot script as well as directly in a terminal.


Best
Ale

Re: Reload IPtables

[Reindl Harald]

Am 28.06.21 um 09:32 schrieb Alessandro Vesely:
> On Sat 26/Jun/2021 12:43:45 +0200 Reindl Harald wrote:
>>>>
>>>> /usr/sbin/ipset -file /etc/sysconfig/ipset restore
>>>> /usr/sbin/iptables-nft-restore /etc/sysconfig/iptables
>>>> /usr/sbin/sysctl -q --load=/etc/sysctl*.conf
>>>>
>>>> that way first all rules are loaded atomic and *then* "ip_forward" 
>>>> and friends are set to avoid a leak at boot
>>>
>>> it may be good for you pro administrators with complex 
>>> configurations...I have all in one file and do not need to bother 
>>> about 1ms lost during reload nor seeking 10 different config files 
>>> for simple tasks and wasting hours by config. I like easy life.
>>
>> mixing things together which don't belong together like iptables and 
>> sysctl is the opposite of simple as well as running a ton of commands 
>> at boot where it should be a oneliner is also the opposite
> 
> 
> I'm with David here.  Besides sysctl and ipset, there are lots of ip 
> commands, modprobe's, vconfig, and a couple of home-brewed daemons 
> (ipqbdb).  A soundly commented script captures the logic of the network 
> and can be maintained with more coherence than raw commands accumulated 
> along the way.  The only drawback is that most changes, for example 
> punching a hole in the firewall, have to be applied twice, in the boot 
> script as well as directly in a terminal.
and what does this different at boot besides that it's faster and atomic 
compared to a complex and error prone script?

/usr/sbin/ipset -file /etc/sysconfig/ipset restore
/usr/sbin/iptables-nft-restore /etc/sysconfig/iptables
/usr/sbin/sysctl -q --load=/etc/sysctl*.conf

-------------

guess what - i maintain network configs with a single systemd-unit but 
that don't justify not using "restore" commands when they exist and are 
appropriate for the task

-------------

[root@testserver:~]$ cat /etc/systemd/system/network-up.service
[Unit]
DefaultDependencies=no
RefuseManualStop=yes
Description=Network
PartOf=basic.target
PartOf=network-online.target
Before=crond.service timers.target vnstat.service vmtoolsd.service

# Sicherstellen dass Netzwerk-Devices von 'udev' umbenannt wurden
After=sys-subsystem-net-devices-lan.device 
sys-subsystem-net-devices-wan.device
Wants=sys-subsystem-net-devices-lan.device 
sys-subsystem-net-devices-wan.device

[Service]
Type=oneshot
RemainAfterExit=yes
SuccessExitStatus=80
TimeoutStartSec=60

# Firewall-Regeln laden
ExecStart=/usr/sbin/ipset -file /etc/sysconfig/ipset restore
ExecStart=/usr/sbin/iptables-nft-restore /etc/sysconfig/iptables
ExecStart=/usr/sbin/ip6tables-nft-restore /etc/sysconfig/ip6tables

# LAN-Interface konfiguieren
ExecStart=-/usr/sbin/ip addr add 192.168.196.12/255.255.255.0 broadcast 
192.168.196.255 dev lan
ExecStart=-/usr/sbin/ip link set dev lan up

# WAN konfigurieren
ExecStart=-/usr/bin/systemctl start network-wan-dhcp.service

# NIC-Konfiguration
ExecStart=-/usr/sbin/ethtool -G lan rx 512 tx 256
ExecStart=-/usr/sbin/ethtool -K lan lro off
ExecStart=-/usr/sbin/ethtool -G wan rx 512 tx 256
ExecStart=-/usr/sbin/ethtool -K wan lro off

# Routing von VPN/Host-Netzwerken
ExecStart=-/usr/sbin/ip route add 10.0.0.0/24 via 192.168.196.2 dev lan
ExecStart=-/usr/sbin/ip route add 172.17.0.0/24 via 192.168.196.2 dev lan
ExecStart=-/usr/sbin/ip route add 192.168.11.0/24 via 192.168.196.2 dev lan

# Sicherstellen dass 'sysctl' angewendet wird
ExecStart=-/usr/sbin/sysctl -q --load=/etc/sysctl*.conf

[Install]
WantedBy=basic.target

-------------

[root@testserver:~]$ cat /etc/systemd/system/network-wan-dhcp.service
[Unit]
Description=Internet DHCP-Client

[Service]
ExecStartPre=-/usr/sbin/ip link set dev wan multicast off allmulticast 
off up
ExecStart=/usr/sbin/dhclient -4 -q --no-pid --request-options 
subnet-mask,broadcast-address,routers wan

Type=forking
PermissionsStartOnly=yes
SuccessExitStatus=80

Restart=always
RestartSec=5

ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=-/var/lib/dhclient

PrivateTmp=yes
NoNewPrivileges=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
MemoryDenyWriteExecute=yes
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_BROADCAST CAP_NET_RAW

LockPersonality=yes
PrivateDevices=yes
ProtectHostname=yes
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes

UMask=077
SystemCallArchitectures=native
SystemCallFilter=@system-service @network-io @privileged
SystemCallFilter=~@aio @chown @clock @cpu-emulation @debug @keyring 
@module @mount @obsolete @raw-io @reboot @resources @swap

InaccessiblePaths=-/boot
InaccessiblePaths=-/efi
InaccessiblePaths=-/root

Re: Reload IPtables

[Alessandro Vesely, Alessandro Vesely]

On Mon 28/Jun/2021 09:46:50 +0200 Reindl Harald wrote:
> Am 28.06.21 um 09:32 schrieb Alessandro Vesely:
>> On Sat 26/Jun/2021 12:43:45 +0200 Reindl Harald wrote:
>>>>>
>>>>> /usr/sbin/ipset -file /etc/sysconfig/ipset restore
>>>>> /usr/sbin/iptables-nft-restore /etc/sysconfig/iptables
>>>>> /usr/sbin/sysctl -q --load=/etc/sysctl*.conf
>>>>>
>>>>> that way first all rules are loaded atomic and *then* "ip_forward" and 
>>>>> friends are set to avoid a leak at boot
>>>>
>>>> it may be good for you pro administrators with complex configurations...I 
>>>> have all in one file and do not need to bother about 1ms lost during reload 
>>>> nor seeking 10 different config files for simple tasks and wasting hours by 
>>>> config. I like easy life.
>>>
>>> mixing things together which don't belong together like iptables and sysctl 
>>> is the opposite of simple as well as running a ton of commands at boot where 
>>> it should be a oneliner is also the opposite
>>
>>
>> I'm with David here.  Besides sysctl and ipset, there are lots of ip 
>> commands, modprobe's, vconfig, and a couple of home-brewed daemons (ipqbdb).  
>> A soundly commented script captures the logic of the network and can be 
>> maintained with more coherence than raw commands accumulated along the way.  
>> The only drawback is that most changes, for example punching a hole in the 
>> firewall, have to be applied twice, in the boot script as well as directly in 
>> a terminal.
> and what does this different at boot besides that it's faster and atomic 
> compared to a complex and error prone script?
> 
> /usr/sbin/ipset -file /etc/sysconfig/ipset restore
> /usr/sbin/iptables-nft-restore /etc/sysconfig/iptables
> /usr/sbin/sysctl -q --load=/etc/sysctl*.conf


A complex script doesn't have to be error prone.

Speed is not a concern, given that boot only happens once every few months.

Setting iptables atomically is not needed because ip link set $interface up commands are issued after iptables -A ones.


> guess what - i maintain network configs with a single systemd-unit but that 
> don't justify not using "restore" commands when they exist and are appropriate 
> for the task
> 
> -------------
> 
> [root@testserver:~]$ cat /etc/systemd/system/network-up.service


That's similar to what I do, except for restoring iptables.  As I don't use systemd, my main script is a shell script in /etc/init.d/.  I paste a few snippets from it.


> # Firewall-Regeln laden
> ExecStart=/usr/sbin/ipset -file /etc/sysconfig/ipset restore
> ExecStart=/usr/sbin/iptables-nft-restore /etc/sysconfig/iptables
> ExecStart=/usr/sbin/ip6tables-nft-restore /etc/sysconfig/ip6tables
> 
> # LAN-Interface konfiguieren
> ExecStart=-/usr/sbin/ip addr add 192.168.196.12/255.255.255.0 broadcast 192.168.196.255 dev lan
> ExecStart=-/usr/sbin/ip link set dev lan up


Similar at mine, except as noted.  My script starts by setting numbers, like so:

# Network setup.
# Using this is more direct and precise than ifup/ifdown, since
# all IPs are static. (However, still missing a failover strategy)
#
# interfaces names, eth{0,1,2,3,4}r are defined in /etc/udev/rules.d/70-persistent-net.rules

fastweb_base=192.168.4
fastweb_if=eth0r
fastweb_bits=24
fastweb_ip=$fastweb_base.1
fastweb_cidr=$fastweb_ip/$fastweb_bits
fastweb_peer=$fastweb_base.254
fastweb_net=$fastweb_base.0/$fastweb_bits

# set fastweb_tracehost
fastweb_tracehost="93.63.100.61"

eutelia_base=62.94.243
eutelia_bits=28
#eutelia_bits=30
eutelia_ip=$eutelia_base.226
eutelia_cidr=$eutelia_ip/$eutelia_bits
# Sun 04 Nov 2018: 225 = Destination Host Unreachable
# eutelia_peer=$eutelia_base.225
eutelia_peer=62.94.107.161
eutelia_net=$eutelia_base.224/$eutelia_bits

# setting eutelia=eth3r (leftmost), interna = eth2r (rightmost)
# vlan
eutelia_if_raw=eth3r
eutelia_if=${eutelia_if_raw}.2


I left old values commented out, rather than deleting them.  I try and use the same names for shell variables, names in rt_tables and iptables.  Device names differ.  I annotate these cross referencing in comments.

That way, I can then use shell variables in iptables commands as in the next snippet below.  How do you handle renumbering otherwise?


#########################
# for policy checking, matrix subdivision is used to gather
# packets into four chains: external and internal _in, and the
# two forwarding directions (interna2externa, externa2interna)

# first matrix subdivision
iptables -A INPUT -i $interna_if -j interna_in
iptables -A INPUT -i $eutelia_if -j eutelia_in
iptables -A INPUT -i $fastweb_if -j fastweb_in
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i tun0 -j externa_in

iptables -A FORWARD -i $interna_if -o $fastweb_if -j interna2externa
iptables -A FORWARD -i $interna_if -o $eutelia_if -j interna2externa
iptables -A FORWARD -i $eutelia_if -o $interna_if -j eutelia2interna
iptables -A FORWARD -i $fastweb_if -o $interna_if -j fastweb2interna


And eventually:


# interfaces
ip addr add $fastweb_cidr dev $fastweb_if broadcast + scope global
ip link set $fastweb_if up

# Sun 04 Nov 2018: Setting up the raw device as well...
ip addr add $eutelia_cidr dev $eutelia_if broadcast + scope global
ip link set $eutelia_if_raw up
ip link set $eutelia_if up


> # NIC-Konfiguration
> ExecStart=-/usr/sbin/ethtool -G lan rx 512 tx 256
> ExecStart=-/usr/sbin/ethtool -K lan lro off
> ExecStart=-/usr/sbin/ethtool -G wan rx 512 tx 256
> ExecStart=-/usr/sbin/ethtool -K wan lro off


I hadn't had to do that, yet (been lucky with autoconf?)


> # Routing von VPN/Host-Netzwerken
> ExecStart=-/usr/sbin/ip route add 10.0.0.0/24 via 192.168.196.2 dev lan
> ExecStart=-/usr/sbin/ip route add 172.17.0.0/24 via 192.168.196.2 dev lan
> ExecStart=-/usr/sbin/ip route add 192.168.11.0/24 via 192.168.196.2 dev lan
> 
> # Sicherstellen dass 'sysctl' angewendet wird
> ExecStart=-/usr/sbin/sysctl -q --load=/etc/sysctl*.conf


Shouldn't this be automatic?


> [root@testserver:~]$ cat /etc/systemd/system/network-wan-dhcp.service
> [Unit]
> Description=Internet DHCP-Client


I set up DHCP independently of the network.  It only listens to the internal interface, so it's somewhat easier.  I consider it a separate issue.


Best
Ale
-- 

Re: Reload IPtables

[Kerin Millar]

On Mon, 28 Jun 2021 11:23:36 +0200
Alessandro Vesely <vesely@tana.it> wrote:

> I left old values commented out, rather than deleting them.  I try and use the same names for shell variables, names in rt_tables and iptables.  Device names differ.  I annotate these cross referencing in comments.
> 
> That way, I can then use shell variables in iptables commands as in the next snippet below.  How do you handle renumbering otherwise?

The desire to expand shell variables is not a compelling argument for eschewing the obvious benefits of using iptables-restore(8). Consider the following.

iptables-restore <<EOF || exit
*filter

:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

:eutelia_in [0:0]
:externa_in [0:0]
:fastweb_in [0:0]
:interna_in [0:0]

-A INPUT -i $interna_if -j interna_in
-A INPUT -i $eutelia_if -j eutelia_in
-A INPUT -i $fastweb_if -j fastweb_in
-A INPUT -i lo -j ACCEPT
-A INPUT -i tun0 -j externa_in

# and so on ...

COMMIT
EOF

Now you benefit from atomicity (the rules will either be committed at once, in full, or not at all) and proper error handling (the exit status value of iptables-restore is meaningful and acted upon). Further, should you prefer to indent the body of the heredoc, you may write <<-EOF, though only leading tab characters will be stripped out.

-- 
Kerin Millar

Re: Reload IPtables

[Reindl Harald]

Am 28.06.21 um 11:23 schrieb Alessandro Vesely:
> A complex script doesn't have to be error prone.

it is by definition more error prone than a simple restore which has 
exactly that job and it makes no sense to argue about such simple facts

do what you want but stop talking nonense when it comes to best practice

> Speed is not a concern, given that boot only happens once every few months.

i care always about speed

> Setting iptables atomically is not needed because ip link set $interface 
> up commands are issued after iptables -A ones.

irrelevant


>> # NIC-Konfiguration
>> ExecStart=-/usr/sbin/ethtool -G lan rx 512 tx 256
>> ExecStart=-/usr/sbin/ethtool -K lan lro off
>> ExecStart=-/usr/sbin/ethtool -G wan rx 512 tx 256
>> ExecStart=-/usr/sbin/ethtool -K wan lro off
> 
> 
> I hadn't had to do that, yet (been lucky with autoconf?)

bla - you don't want LRO on a router because it breaks end-to-end 
principle and maybe you heard about buffer bloat

>> # Sicherstellen dass 'sysctl' angewendet wird
>> ExecStart=-/usr/sbin/sysctl -q --load=/etc/sysctl*.conf
> 
> 
> Shouldn't this be automatic?

what when i don't want that automatic to avoid all sort of warnings when 
that automatic fires before iptables is loaded and so all the conntrack 
values are unknown?

> I set up DHCP independently of the network.  It only listens to the 
> internal interface, so it's somewhat easier.  I consider it a separate 
> issue

you didn't realize the difference between dhcp client/server!

Re: Reload IPtables

[Alessandro Vesely, Alessandro Vesely]

On Mon 28/Jun/2021 12:17:11 +0200 Reindl Harald wrote:
> Am 28.06.21 um 11:23 schrieb Alessandro Vesely:
>> A complex script doesn't have to be error prone.
> 
> it is by definition more error prone than a simple restore which has exactly 
> that job and it makes no sense to argue about such simple facts


As Kerin showed, restore is not intrinsically simpler, as it has to deal with 
the same amount of data.  It is only laid down in a different format.  The 
shell format is more verbose, but has some advantages:

* it allows to test each single command separately, and

* its format is time-honored and fully documented.


> do what you want but stop talking nonsense when it comes to best practice 


One "best practice" that I'd object to is blindly restoring whatever was saved 
on shutdown.  How can one control that?  Booting with some clean, well-defined 
data looks safer.


Best
Ale
-- 

Re: Reload IPtables

[Reindl Harald]

Am 28.06.21 um 13:47 schrieb Alessandro Vesely:
> On Mon 28/Jun/2021 12:17:11 +0200 Reindl Harald wrote:
>> Am 28.06.21 um 11:23 schrieb Alessandro Vesely:
>>> A complex script doesn't have to be error prone.
>>
>> it is by definition more error prone than a simple restore which has 
>> exactly that job and it makes no sense to argue about such simple facts
> 
> 
> As Kerin showed, restore is not intrinsically simpler, as it has to deal 
> with the same amount of data.  It is only laid down in a different 
> format.  

for the sake of god you are not supposed to deal with that format as 
human at all - you only need to know where you write it and load it from 
there

> The shell format is more verbose, but has some advantages:

not at boot time

> * it allows to test each single command separately

off-topic in the case of reload the complete ruleset

> * its format is time-honored and fully documented.

off-topic in the case of reload the complete ruleset

>> do what you want but stop talking nonsense when it comes to best practice 
> 
> One "best practice" that I'd object to is blindly restoring whatever was 
> saved on shutdown.  How can one control that?  Booting with some clean, 
> well-defined data looks safer

WTF: there is nothing magically or blindly saved and changed at 
shutdown, it's the whole state as it was, the outcome from your script

do you guys not realize that your shellscripts are fine as mine are but 
at the end the iptables ruleset has a defined state which want you have 
restored 1:1 at boot

this whole discusssion is embarrassing and especially when the target 
audience in this case is a noob-user it's idiotic not follow best practices

nobody gives a shit how you create the ruleset and nobody right in his 
mind would touch the save-file by anything else but "iptables-save 
--file path" as nobody right in his mind would load it by anything else 
than  "iptables-nft-restore path"

arguments like "i don't care if it's atomic in my special situation" and 
"i don't care how long it takes in my special situation" are dumb in 
context of the subject

please stop spreading bullshit - we have enough idiots out there blindly 
follow whatever they read whereever on the internet without the 
slightest clue what they are doing

YOU can do what you want on YOUR machine but best practices are there to 
avoid endless threads over and over again when someone has a problem and 
nobody knows about his setup and your "i do everything like i want" is 
off-topic

Re: Reload IPtables

[Stephen Satchell]

On 6/28/21 4:47 AM, Alessandro Vesely wrote:
> One "best practice" that I'd object to is blindly restoring whatever was 
> saved on shutdown.  How can one control that?  Booting with some clean, 
> well-defined data looks safer.

In my home-brew iptables(8) scripts written as a shell script quite a 
few years ago, I use shell functions to actually build the commands. 
The specifications are coded in shell arrays, one for each type 
"pinhole".  This resulted in a mostly-closed implementation.

Originally, the script was invoked at boot time via rc.local entry. 
When I would make a change, I would then manually run the script as 
root.  Manual changes are few and far between, usually because I've 
taken on a new task that requires a few more ports be opened.

With my move to Ubuntu, plus replacing my LAN-to-public interface with a 
Unity appliance, I've not taken the time to port the script to Python, 
nor to build a systemd configuration for it.  Indeed, with Ubuntu I'm 
using UFW, adding reverse path filtering plus rate limiting on pings.

Re: Reload IPtables

[Kerin Millar]

On Mon, 28 Jun 2021 14:03:30 +0200
Reindl Harald <h.reindl@thelounge.net> wrote:

> >> do what you want but stop talking nonsense when it comes to best practice 
> > 
> > One "best practice" that I'd object to is blindly restoring whatever was 
> > saved on shutdown.  How can one control that?  Booting with some clean, 
> > well-defined data looks safer
> 
> WTF: there is nothing magically or blindly saved and changed at 
> shutdown, it's the whole state as it was, the outcome from your script

Not that I can speak on Allesandro's behalf but I'm presuming it's a reference to the save-upon-stop behaviour that may occur as a consequence of the integration performed by certain distro vendors. For example, Gentoo has a SAVE_ON_STOP option that its iptables runscript honours. I'm not sure that I've ever seen it be referred to as a good pratice, per se, but some people appreciate having such options at their disposal.

-- 
Kerin Millar

Re: Reload IPtables

[Reindl Harald]

Am 28.06.21 um 15:46 schrieb Kerin Millar:
> On Mon, 28 Jun 2021 14:03:30 +0200
> Reindl Harald <h.reindl@thelounge.net> wrote:
> 
>>>> do what you want but stop talking nonsense when it comes to best practice
>>>
>>> One "best practice" that I'd object to is blindly restoring whatever was
>>> saved on shutdown.  How can one control that?  Booting with some clean,
>>> well-defined data looks safer
>>
>> WTF: there is nothing magically or blindly saved and changed at
>> shutdown, it's the whole state as it was, the outcome from your script
> 
> Not that I can speak on Allesandro's behalf but I'm presuming it's a reference to the save-upon-stop behaviour that may occur as a consequence of the integration performed by certain distro vendors. For example, Gentoo has a SAVE_ON_STOP option that its iptables runscript honours. I'm not sure that I've ever seen it be referred to as a good pratice, per se, but some people appreciate having such options at their disposal

and how do you think should there be something different as you are using?

don't you simply not understand what save/restore does?
your active ruleset don't fall from heaven

it's not magically changed unless you change something with iptables or 
your script

and hell that's why when you changed something and want to reload the 
last boot state you restore and you are done - that's the topic here

Re: Reload IPtables

[Kerin Millar]

On Mon, 28 Jun 2021 18:35:59 +0200
Reindl Harald <h.reindl@thelounge.net> wrote:

> 
> 
> Am 28.06.21 um 15:46 schrieb Kerin Millar:
> > On Mon, 28 Jun 2021 14:03:30 +0200
> > Reindl Harald <h.reindl@thelounge.net> wrote:
> > 
> >>>> do what you want but stop talking nonsense when it comes to best practice
> >>>
> >>> One "best practice" that I'd object to is blindly restoring whatever was
> >>> saved on shutdown.  How can one control that?  Booting with some clean,
> >>> well-defined data looks safer
> >>
> >> WTF: there is nothing magically or blindly saved and changed at
> >> shutdown, it's the whole state as it was, the outcome from your script
> > 
> > Not that I can speak on Allesandro's behalf but I'm presuming it's a reference to the save-upon-stop behaviour that may occur as a consequence of the integration performed by certain distro vendors. For example, Gentoo has a SAVE_ON_STOP option that its iptables runscript honours. I'm not sure that I've ever seen it be referred to as a good pratice, per se, but some people appreciate having such options at their disposal
> 
> and how do you think should there be something different as you are using?

I can't parse that.

> 
> don't you simply not understand what save/restore does?
> your active ruleset don't fall from heaven

I'm not sure who you are addressing at this point but you can be assured that I am aware of what saving and restoring entails.

> 
> it's not magically changed unless you change something with iptables or 
> your script
> 
> and hell that's why when you changed something and want to reload the 
> last boot state you restore and you are done - that's the topic here

Granted, the thread does seem to have meandered out into the weeds at this point. With that, I'm out.

-- 
Kerin Millar

Re: Reload IPtables

[Reindl Harald]

Am 28.06.21 um 19:10 schrieb Kerin Millar:
> On Mon, 28 Jun 2021 18:35:59 +0200
> Reindl Harald <h.reindl@thelounge.net> wrote:
> 
>>
>>
>> Am 28.06.21 um 15:46 schrieb Kerin Millar:
>>> On Mon, 28 Jun 2021 14:03:30 +0200
>>> Reindl Harald <h.reindl@thelounge.net> wrote:
>>>
>>>>>> do what you want but stop talking nonsense when it comes to best practice
>>>>>
>>>>> One "best practice" that I'd object to is blindly restoring whatever was
>>>>> saved on shutdown.  How can one control that?  Booting with some clean,
>>>>> well-defined data looks safer
>>>>
>>>> WTF: there is nothing magically or blindly saved and changed at
>>>> shutdown, it's the whole state as it was, the outcome from your script
>>>
>>> Not that I can speak on Allesandro's behalf but I'm presuming it's a reference to the save-upon-stop behaviour that may occur as a consequence of the integration performed by certain distro vendors. For example, Gentoo has a SAVE_ON_STOP option that its iptables runscript honours. I'm not sure that I've ever seen it be referred to as a good pratice, per se, but some people appreciate having such options at their disposal
>>
>> and how do you think should there be something different as you are using?
> 
> I can't parse that.

what exactly can't you parse?

if at all something is saved at shutdown it's what you are currently using

>> don't you simply not understand what save/restore does?
>> your active ruleset don't fall from heaven
> 
> I'm not sure who you are addressing at this point but you can be assured that I am aware of what saving and restoring entails.

whoever thinks "blindly restoring whatever was saved on shutdown"

>> it's not magically changed unless you change something with iptables or
>> your script
>>
>> and hell that's why when you changed something and want to reload the
>> last boot state you restore and you are done - that's the topic here
> 
> Granted, the thread does seem to have meandered out into the weeds at this point. With that, I'm out

that whole thread was useless and should have been pointed to the 
distribution mailing list of the OP because there is nothing like 
"Reload IPtables" which works everywhere

bwell, that would have been fine when someone steps in using the same 
distribution but coming up to a newbie with homegrown solutions where he 
would be left alone even at distro channels later is simply idiotic

Re: Reload IPtables

[Alessandro Vesely, Alessandro Vesely]

On Mon 28/Jun/2021 14:03:30 +0200 Reindl Harald wrote:
> Am 28.06.21 um 13:47 schrieb Alessandro Vesely:
>> On Mon 28/Jun/2021 12:17:11 +0200 Reindl Harald wrote:
>>> Am 28.06.21 um 11:23 schrieb Alessandro Vesely:
> 
>>> do what you want but stop talking nonsense when it comes to best practice 
>>
>> One "best practice" that I'd object to is blindly restoring whatever was 
>> saved on shutdown.  How can one control that?  Booting with some clean, 
>> well-defined data looks safer
> 
> WTF: there is nothing magically or blindly saved and changed at shutdown, it's 
> the whole state as it was, the outcome from your script
> 
> do you guys not realize that your shellscripts are fine as mine are but at the 
> end the iptables ruleset has a defined state which want you have restored 1:1 
> at boot


If the defined state is the result of a shell script, re-running the same shell 
script should result in the same state.  Restoring from the last-saved state 
may be faster/ cooler, but roughly equivalent.

However, what if, one day, something wrong happens and you try to quickly fix 
the rules.  At some point you realize the rules were fine, the problem was 
somewhere else and now you need to reboot.  Hm... how do you return to the 
previous state?  Maybe the shell script that originally gave place to the 
target state run in 2008 for the last time.  The last iptables-save output 
looks older than some changes applied a couple of weeks ago —there's been no 
reboot in the meantime.  What do you do in that case?


> this whole discusssion is embarrassing and especially when the target audience 
> in this case is a noob-user it's idiotic not follow best practices
> 
> nobody gives a shit how you create the ruleset and nobody right in his mind 
> would touch the save-file by anything else but "iptables-save --file path" as 
> nobody right in his mind would load it by anything else than  
> "iptables-nft-restore path"


That way you exclude comments.  Don't you think it's relevant to annotate why 
you issued a given rule?  What if someone else will have to maintain the 
ruleset?  Or even yourself, if you can happen to forget what daemon is expected 
to filter packets in a given nf queue, or what reason did you have in mind when 
you defined a given chain rather than jumping directly to the next target? 
Where do you write down such maintenance hints?


> please stop spreading bullshit - we have enough idiots out there blindly follow 
> whatever they read wherever on the internet without the slightest clue what 
> they are doing
> 
> YOU can do what you want on YOUR machine but best practices are there to avoid 
> endless threads over and over again when someone has a problem and nobody knows 
> about his setup and your "i do everything like i want" is off-topic


I think that any "idiots out there" who might be following this thread can 
judge by themselves.  However, if you think this is bullshit, you should stop 
amplifying it, because probably that's what you're doing.  There is no well 
established /best practice/, because iptables rules are managed in so many 
different ways.  Don't think that calling my arguments *bullshit* earns more 
points to yours:  You never know what's on an idiot's mind.


Best
Ale
-- 

Re: Reload IPtables

[Reindl Harald]

Am 28.06.21 um 19:35 schrieb Alessandro Vesely:
> On Mon 28/Jun/2021 14:03:30 +0200 Reindl Harald wrote:
>> Am 28.06.21 um 13:47 schrieb Alessandro Vesely:
>>> On Mon 28/Jun/2021 12:17:11 +0200 Reindl Harald wrote:
>>>> Am 28.06.21 um 11:23 schrieb Alessandro Vesely:
>>
>>>> do what you want but stop talking nonsense when it comes to best 
>>>> practice 
>>>
>>> One "best practice" that I'd object to is blindly restoring whatever 
>>> was saved on shutdown.  How can one control that?  Booting with some 
>>> clean, well-defined data looks safer
>>
>> WTF: there is nothing magically or blindly saved and changed at 
>> shutdown, it's the whole state as it was, the outcome from your script
>>
>> do you guys not realize that your shellscripts are fine as mine are 
>> but at the end the iptables ruleset has a defined state which want you 
>> have restored 1:1 at boot
> 
> If the defined state is the result of a shell script, re-running the 
> same shell script should result in the same state.  Restoring from the 
> last-saved state may be faster/ cooler, but roughly equivalent

* it's faster
* it's atomic
* it has less dependencies
* it has less involved software
* it has less chances of breaking bugs

it's not about "cool" but acting with a brain and following the unix 
way: one tool for one job

give me *one* vaild reason to waste ressources other than "everybody 
does, that's why machines 10000 times faster than 30 years ago are in 
many cases as slow because we waste ressources when they are available"

only the idea doing "roughly equivalent" but way slower when it costs 
you *one line* do do it fast, clean and atomic should get you fired 
whereever you work

but argue about it is braindead

Re: Reload IPtables

[Neal P. Murphy]

On Mon, 28 Jun 2021 10:43:10 +0100
Kerin Millar <kfm@plushkava.net> wrote:

> Now you benefit from atomicity (the rules will either be committed at once, in full, or not at all) and proper error handling (the exit status value of iptables-restore is meaningful and acted upon). Further, should you prefer to indent the body of the heredoc, you may write <<-EOF, though only leading tab characters will be stripped out.
> 

[minor digression]

Is iptables-restore truly atomic in *all* cases? Some years ago, I found through experimentation that some rules were 'lost' when restoring more than 25 000 rules. If I placed a COMMIT every 20 000 rules or so, then all rules would be properly loaded. I think COMMITs break atomicity. I tested with 100k to 1M rules. I was comparing the efficiency of iptables-restore with another tool that read from STDIN; the other tool was about 5% more efficient.

Re: Reload IPtables

[Neal P. Murphy]

On Mon, 28 Jun 2021 10:43:10 +0100
Kerin Millar <kfm@plushkava.net> wrote:

> Now you benefit from atomicity (the rules will either be committed at once, in full, or not at all) and proper error handling (the exit status value of iptables-restore is meaningful and acted upon). Further, should you prefer to indent the body of the heredoc, you may write <<-EOF, though only leading tab characters will be stripped out.
> 

[minor digression]

Is iptables-restore truly atomic in *all* cases? Some years ago, I found through experimentation that some rules were 'lost' when restoring more than 25 000 rules. If I placed a COMMIT every 20 000 rules or so, then all rules would be properly loaded. I think COMMITs break atomicity. I tested with 100k to 1M rules. I was comparing the efficiency of iptables-restore with another tool that read from STDIN; the other tool was about 5% more efficient.

Re: Reload IPtables

[Pablo Neira Ayuso]

On Mon, Jun 28, 2021 at 10:02:41PM -0400, Neal P. Murphy wrote:
> On Mon, 28 Jun 2021 10:43:10 +0100
> Kerin Millar <kfm@plushkava.net> wrote:
> 
> > Now you benefit from atomicity (the rules will either be committed at once, in full, or not at all) and proper error handling (the exit status value of iptables-restore is meaningful and acted upon). Further, should you prefer to indent the body of the heredoc, you may write <<-EOF, though only leading tab characters will be stripped out.
> > 
> 
> [minor digression]
> 
> Is iptables-restore truly atomic in *all* cases?

Packets either see the old table or the new table, no intermediate
ruleset state is exposed to packet path.

> Some years ago, I found through experimentation that some rules were
> 'lost' when restoring more than 25 000 rules.

Could you specify kernel and userspace versions? Rules are not 'lost'
when restoring large rulesets.

> If I placed a COMMIT every 20 000 rules or so, then all rules would
> be properly loaded. I think COMMITs break atomicity.

Why are you placing COMMIT in every few rules 20 000 rules?

> I tested with 100k to 1M rules.

iptables is handling very large rulesets already.

> I was comparing the efficiency of iptables-restore with another tool
> that read from STDIN; the other tool was about 5% more efficient.

Could you please specify what other tool are you refering to?

iptables-restore is the best practise to restore your ruleset.

You should also iptables-restore to perform incremental updates via
--noflush.

Re: Reload IPtables

[Kerin Millar]

On Mon, 28 Jun 2021 22:02:41 -0400
"Neal P. Murphy" <neal.p.murphy@alum.wpi.edu> wrote:

> On Mon, 28 Jun 2021 10:43:10 +0100
> Kerin Millar <kfm@plushkava.net> wrote:
> 
> > Now you benefit from atomicity (the rules will either be committed at once, in full, or not at all) and proper error handling (the exit status value of iptables-restore is meaningful and acted upon). Further, should you prefer to indent the body of the heredoc, you may write <<-EOF, though only leading tab characters will be stripped out.
> > 
> 
> [minor digression]
> 
> Is iptables-restore truly atomic in *all* cases? Some years ago, I found through experimentation that some rules were 'lost' when restoring more than 25 000 rules. If I placed a COMMIT every 20 000 rules or so, then all rules would be properly loaded. I think COMMITs break atomicity. I tested with 100k to 1M rules. I was comparing the efficiency of iptables-restore with another tool that read from STDIN; the other tool was about 5% more efficient.

I believe that you are correct on both counts; at least, as far as iptables-legacy-restore is concerned. My understanding is that iptables-nft-restore should not 'lose' rules because there is an initial parsing stage, after which it conveys the payload as a series of netlink packets to nftables, which is supposed to be immune to this issue. It would be nice to get a confirmation one way or the other from a Netfilter developer.

Until now, I had thought that iptables-nft-restore addressed the issue of committing large batches of rules but, having just conducted a quick test, it does not appear to be the case. While I wasn't able to induce either utility to partially load a ruleset, I found that both fail outright upon pushing the number of rules beyond a certain threshold within a given chain. To my surprise, that threshold appears to be lower in the case of iptables-nft-restore.

-- 
Kerin Millar

Re: Reload IPtables

[slow_speed]

On 6/28/21 10:02 PM, Neal P. Murphy wrote:
> On Mon, 28 Jun 2021 10:43:10 +0100
> Kerin Millar <kfm@plushkava.net> wrote:
> 
>> Now you benefit from atomicity (the rules will either be committed at once, in full, or not at all) and proper error handling (the exit status value of iptables-restore is meaningful and acted upon). Further, should you prefer to indent the body of the heredoc, you may write <<-EOF, though only leading tab characters will be stripped out.
>>
> 
> [minor digression]
> 
> Is iptables-restore truly atomic in *all* cases? Some years ago, I found through experimentation that some rules were 'lost' when restoring more than 25 000 rules. If I placed a COMMIT every 20 000 rules or so, then all rules would be properly loaded. I think COMMITs break atomicity. I tested with 100k to 1M rules. I was comparing the efficiency of iptables-restore with another tool that read from STDIN; the other tool was about 5% more efficient.
> 

Please explain why you might have so many rules.  My server is pushing 
it at a dozen.

Re: Reload IPtables

[Reindl Harald]

Am 29.06.21 um 16:52 schrieb slow_speed@att.net:
> 
> 
> On 6/28/21 10:02 PM, Neal P. Murphy wrote:
>> On Mon, 28 Jun 2021 10:43:10 +0100
>> Kerin Millar <kfm@plushkava.net> wrote:
>>
>>> Now you benefit from atomicity (the rules will either be committed at 
>>> once, in full, or not at all) and proper error handling (the exit 
>>> status value of iptables-restore is meaningful and acted upon). 
>>> Further, should you prefer to indent the body of the heredoc, you may 
>>> write <<-EOF, though only leading tab characters will be stripped out.
>>>
>>
>> [minor digression]
>>
>> Is iptables-restore truly atomic in *all* cases? Some years ago, I 
>> found through experimentation that some rules were 'lost' when 
>> restoring more than 25 000 rules. If I placed a COMMIT every 20 000 
>> rules or so, then all rules would be properly loaded. I think COMMITs 
>> break atomicity. I tested with 100k to 1M rules. I was comparing the 
>> efficiency of iptables-restore with another tool that read from STDIN; 
>> the other tool was about 5% more efficient.
>>
> 
> Please explain why you might have so many rules.  My server is pushing 
> it at a dozen

likely because people don't use "ipset" and "chains" instead repeat the 
same stuff again and again so that every single package has to travel 
over hundrets and thousands of rules :-)

Re: Reload IPtables

[slow_speed]

On 6/29/21 11:18 AM, Reindl Harald wrote:
> 
> 
> Am 29.06.21 um 16:52 schrieb slow_speed@att.net:
>>
>>
>> On 6/28/21 10:02 PM, Neal P. Murphy wrote:
>>> On Mon, 28 Jun 2021 10:43:10 +0100
>>> Kerin Millar <kfm@plushkava.net> wrote:
>>>
>>>> Now you benefit from atomicity (the rules will either be committed 
>>>> at once, in full, or not at all) and proper error handling (the exit 
>>>> status value of iptables-restore is meaningful and acted upon). 
>>>> Further, should you prefer to indent the body of the heredoc, you 
>>>> may write <<-EOF, though only leading tab characters will be 
>>>> stripped out.
>>>>
>>>
>>> [minor digression]
>>>
>>> Is iptables-restore truly atomic in *all* cases? Some years ago, I 
>>> found through experimentation that some rules were 'lost' when 
>>> restoring more than 25 000 rules. If I placed a COMMIT every 20 000 
>>> rules or so, then all rules would be properly loaded. I think COMMITs 
>>> break atomicity. I tested with 100k to 1M rules. I was comparing the 
>>> efficiency of iptables-restore with another tool that read from 
>>> STDIN; the other tool was about 5% more efficient.
>>>
>>
>> Please explain why you might have so many rules.  My server is pushing 
>> it at a dozen
> 
> likely because people don't use "ipset" and "chains" instead repeat the 
> same stuff again and again so that every single package has to travel 
> over hundrets and thousands of rules :-)

Exactly my thoughts.  Of course I understand that there may be long 
lists in some odd situations, but I wonder what kind of server is being 
referenced.

Re: Reload IPtables

[Neal P. Murphy]

On Tue, 29 Jun 2021 10:37:18 +0200
Pablo Neira Ayuso <pablo@netfilter.org> wrote:

> On Mon, Jun 28, 2021 at 10:02:41PM -0400, Neal P. Murphy wrote:
> > On Mon, 28 Jun 2021 10:43:10 +0100
> > Kerin Millar <kfm@plushkava.net> wrote:
> >   
> > > Now you benefit from atomicity (the rules will either be committed at once, in full, or not at all) and proper error handling (the exit status value of iptables-restore is meaningful and acted upon). Further, should you prefer to indent the body of the heredoc, you may write <<-EOF, though only leading tab characters will be stripped out.
> > >   
> > 
> > [minor digression]
> > 
> > Is iptables-restore truly atomic in *all* cases?  
> 
> Packets either see the old table or the new table, no intermediate
> ruleset state is exposed to packet path.
> 
> > Some years ago, I found through experimentation that some rules were
> > 'lost' when restoring more than 25 000 rules.  
> 
> Could you specify kernel and userspace versions? Rules are not 'lost'
> when restoring large rulesets.

This goes back to late '10, early '11: linux 2.6.35, iptables 1.4.10; possibly even earlier releases. I don't recall trying the experiment since.

> 
> > If I placed a COMMIT every 20 000 rules or so, then all rules would
> > be properly loaded. I think COMMITs break atomicity.  
> 
> Why are you placing COMMIT in every few rules 20 000 rules?

If I recall correctly, when I attempted to restore/load more than 'N' rules or so back then, a few rules at that 'N' 'boundary' would not be in the final iptables ruleset. IIRC, it didn't matter how quickly or slowly I added the rules. By including a COMMIT every 20k rules or so, all of the rules I loaded would be added, be it 10k or 100k (or more).

There was also a vmalloc failure up around 130k-150k rules.

A couple references:
  - https://marc.info/?l=netfilter&m=133814281919741&w=2
  - https://community.smoothwall.org/forum/viewtopic.php?p=292390#p292390

> 
> > I tested with 100k to 1M rules.  
> 
> iptables is handling very large rulesets already.
> 
> > I was comparing the efficiency of iptables-restore with another tool
> > that read from STDIN; the other tool was about 5% more efficient.  
> 
> Could you please specify what other tool are you refering to?

The tool is ipbatch (part of Smoothwall Express). It was written because, at least back then, iptables was not able to read from STDIN. Smoothwall Express reads its config/settings files and generates the firewall rules on the fly and pipes them to ipbatch. Also, the rules are generated by function/application, not by table; iptables-restore would not be usable without major changes to the way Smoothwall Express generates its firewall rules.

Neal

Re: Reload IPtables

[Neal P. Murphy]

On Tue, 29 Jun 2021 10:37:18 +0200
Pablo Neira Ayuso <pablo@netfilter.org> wrote:

> On Mon, Jun 28, 2021 at 10:02:41PM -0400, Neal P. Murphy wrote:
> > On Mon, 28 Jun 2021 10:43:10 +0100
> > Kerin Millar <kfm@plushkava.net> wrote:
> >   
> > > Now you benefit from atomicity (the rules will either be committed at once, in full, or not at all) and proper error handling (the exit status value of iptables-restore is meaningful and acted upon). Further, should you prefer to indent the body of the heredoc, you may write <<-EOF, though only leading tab characters will be stripped out.
> > >   
> > 
> > [minor digression]
> > 
> > Is iptables-restore truly atomic in *all* cases?  
> 
> Packets either see the old table or the new table, no intermediate
> ruleset state is exposed to packet path.
> 
> > Some years ago, I found through experimentation that some rules were
> > 'lost' when restoring more than 25 000 rules.  
> 
> Could you specify kernel and userspace versions? Rules are not 'lost'
> when restoring large rulesets.

This goes back to late '10, early '11: linux 2.6.35, iptables 1.4.10; possibly even earlier releases. I don't recall trying the experiment since.

> 
> > If I placed a COMMIT every 20 000 rules or so, then all rules would
> > be properly loaded. I think COMMITs break atomicity.  
> 
> Why are you placing COMMIT in every few rules 20 000 rules?

If I recall correctly, when I attempted to restore/load more than 'N' rules or so back then, a few rules at that 'N' 'boundary' would not be in the final iptables ruleset. IIRC, it didn't matter how quickly or slowly I added the rules. By including a COMMIT every 20k rules or so, all of the rules I loaded would be added, be it 10k or 100k (or more).

There was also a vmalloc failure up around 130k-150k rules.

A couple references:
  - https://marc.info/?l=netfilter&m=133814281919741&w=2
  - https://community.smoothwall.org/forum/viewtopic.php?p=292390#p292390

> 
> > I tested with 100k to 1M rules.  
> 
> iptables is handling very large rulesets already.
> 
> > I was comparing the efficiency of iptables-restore with another tool
> > that read from STDIN; the other tool was about 5% more efficient.  
> 
> Could you please specify what other tool are you refering to?

The tool is ipbatch (part of Smoothwall Express). It was written because, at least back then, iptables was not able to read from STDIN. Smoothwall Express reads its config/settings files and generates the firewall rules on the fly and pipes them to ipbatch. Also, the rules are generated by function/application, not by table; iptables-restore would not be usable without major changes to the way Smoothwall Express generates its firewall rules.

Neal

Re: Reload IPtables

[Neal P. Murphy]

On Tue, 29 Jun 2021 10:52:38 -0400
slow_speed@att.net wrote:

> On 6/28/21 10:02 PM, Neal P. Murphy wrote:
> > On Mon, 28 Jun 2021 10:43:10 +0100
> > Kerin Millar <kfm@plushkava.net> wrote:
> >   
> >> Now you benefit from atomicity (the rules will either be committed at once, in full, or not at all) and proper error handling (the exit status value of iptables-restore is meaningful and acted upon). Further, should you prefer to indent the body of the heredoc, you may write <<-EOF, though only leading tab characters will be stripped out.
> >>  
> > 
> > [minor digression]
> > 
> > Is iptables-restore truly atomic in *all* cases? Some years ago, I found through experimentation that some rules were 'lost' when restoring more than 25 000 rules. If I placed a COMMIT every 20 000 rules or so, then all rules would be properly loaded. I think COMMITs break atomicity. I tested with 100k to 1M rules. I was comparing the efficiency of iptables-restore with another tool that read from STDIN; the other tool was about 5% more efficient.
> >   
> 
> Please explain why you might have so many rules.  My server is pushing 
> it at a dozen.

In this particular case, I needed a lot of rules to obtain a reasonable estimate of the relative efficiencies of the two programs, enough rules to mask program initialization time.

I agree that tens of thousands of rules is probably outrageous for most purposes. A good firewall--that restricts outgoing conns, handles TESTNET addresses, isolates traffic between several internal LANs while allowing certain traffic to pass between them, employs NAT, and uses CONNMARKs to tag traffic and to provide traffic stats--can easily use over 600 rules, if not a good deal more. Yet a 1.6GHz Atom N270 can still process four saturated gigE NICs with plenty of cycles to spare with those 600 rules.

N