Difference between revisions of "Talk:Iptables"

From ArchWiki
Jump to navigation Jump to search
(→‎Broken instructions?: rm closed discussion)
Line 51: Line 51:
 
::Going back to {{Bug|33478}} I'd like to add {{Bug|41633}} as a cross-reference here, which already implemented the new {{ic|network-pre.target}} for [https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/nftables&id=0ce3501e78e603fff5ac95a551bb69c411172197 nftables]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:59, 16 September 2014 (UTC)
 
::Going back to {{Bug|33478}} I'd like to add {{Bug|41633}} as a cross-reference here, which already implemented the new {{ic|network-pre.target}} for [https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/nftables&id=0ce3501e78e603fff5ac95a551bb69c411172197 nftables]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:59, 16 September 2014 (UTC)
 
::Anyone watching: {{Bug|33478}} has been closed and the service will gain default dependencies with the next package. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:13, 6 April 2015 (UTC)
 
::Anyone watching: {{Bug|33478}} has been closed and the service will gain default dependencies with the next package. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:13, 6 April 2015 (UTC)
 +
 +
== iptables-save vs iptables -L ==
 +
 +
 +
I am the author of revision 402451, which Lahwaacz undid
 +
with the following reason:
 +
 +
Why isn't iptables-save the alternative? Its output is not
 +
pretty-formatted, the immediately following note no longer applies and
 +
the following uses iptables -L
 +
 +
I strongly lobby for the use of iptables-save. The opposition indicated by Lahwaacz
 +
shows that there is disagreement regarding this matter.
 +
 +
The use ot `iptables-save` should be preferred to `iptables -L` and other variants of the command (`iptables -Ln`, `iptables -Lnv`).
 +
 +
The output of `iptables-save` is much nicer formatted than `iptables -L`.
 +
It produces output that is extremely similiar to the input format, shows the chain
 +
policies in a nice way, doesn't produce extremely long lines of text like `iptables -L`, does not try to resolve IPs to DNS names by default and shows all tables, hence the complete rule set, by default. Therefore `iptables-save` is vastly superior to `iptables -L`.
 +
 +
I do a lot of work in #netfilter on Freenode and newbies commonly assume that the output of `iptables -L` is the complete rule set. Also, the output is bad to read, because it does not conform to the input format, which makes debugging more difficult than necessary. #netfilter is the help channel regarding Linux firewalling and networking in general. It is the place people with Linux networking of firewalling problems go to get help.
 +
 +
Kind regards,
 +
Thermi

Revision as of 20:22, 30 September 2015

Starting iptables before network

Shouldn't this page explain how to set up systemd to start iptables before the network interfaces are up? I read Systemd and I will be trying this:

$ sudo vim /etc/systemd/system/network.service
[Unit]
Description=lan
Requires=iptables.service - added by me 
After=iptables.service - added by me 
Wants=network.target
Before=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=/etc/conf.d/network
ExecStart=/sbin/ip link set dev ${interface} up
ExecStart=/sbin/ip addr add ${address}/${netmask} broadcast ${broadcast} dev ${interface}
ExecStart=/sbin/ip route add default via ${gateway}
ExecStop=/sbin/ip addr flush dev ${interface}
ExecStop=/sbin/ip link set dev ${interface} down
[Install]
WantedBy=multi-user.target

however, I have no clue if this is correct or not. Doru001 (talk) 17:28, 27 January 2013 (UTC)

That's the way to do it. Consider adding "ip6tables.service" for IPv6 connections if it's required. A much cleaner and safer solution would be to have the actual iptables services start before any kind of network is available. This needs a "Before=sysinit.target" (and possibly more) listed in the Unit sections. If you could test it, I'm sure the iptables packager would be happy to hear from you at Bug #33478. --Gilrain (talk) 16:39, 8 February 2013 (UTC)
Following https://bugs.freedesktop.org/show_bug.cgi?id=57773#c7 from your bug report I have done this:
$ cat /usr/lib/systemd/system/iptables.service
[Unit]
Description=Packet Filtering Framework
DefaultDependencies=no
After=systemd-sysctl.service
Before=sysinit.target
[Service]
Type=oneshot
ExecStart=/usr/bin/iptables-restore /etc/iptables/iptables.rules
ExecReload=/usr/bin/iptables-restore /etc/iptables/iptables.rules
ExecStop=/usr/lib/systemd/scripts/iptables-flush
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
Seems to be working, but I don't know how to check that it starts when it should, it is possible that journalctl is not started before it. Doru001 (talk) 14:53, 13 July 2013 (UTC)
Use "systemd-analyze plot > bootchart.svg" to check the complete start-up sequence. You should see iptables.service near the top, sysinit.target in the middle and network.target further down (at least, that what it looks like with UFW). Also, does iptables really need "After=systemd-sysctl.service" or is it there because of a quick copy-paste? --Gilrain (talk) 19:36, 13 July 2013 (UTC)
That was a quick copy-paste, but it makes sense to me to configure the kernel before iptables and iptables before sysinit. If you have a better iptables.service unit then please post it here. Thank you for systemd-analyze plot. Doru001 (talk) 08:58, 14 July 2013 (UTC)
Using Before=sysinit.target in this case would be wrong, it breaks dependencies between targets. Note that iptables.service is WantedBy=multi-user.target, multi-user.target is started after sysinit.target. I think the correct way to do this is by placing iptables.service into basic.target, which is started after sysinit.target but before multi-user.target. All services configuring network interfaces are in multi-user.target, so network.target is necessarily started after basic.target. -- Lahwaacz (talk) 17:40, 25 July 2013 (UTC)
Not really, WantedBy does not mean Before and in fact the start order is: iptables.service, sysinit.target and multi-user.target, with many other units started between them. See Requires in man systemd.unit. Not only that WantedBy has nothing to do with Before as many newcomers believe, but you confuse it with After. So this configuration says: if you start multi-user.target, then also start iptables.service. When should you start iptables.service? Before sysinit.target! I don't know what happens when sysinit.target is already started. And yes, systemd is uncomfortable, to say the least (join us on this). Doru001 (talk) 09:18, 4 September 2013 (UTC)
Going back to FS#33478 I'd like to add FS#41633 as a cross-reference here, which already implemented the new network-pre.target for nftables. --Indigo (talk) 20:59, 16 September 2014 (UTC)
Anyone watching: FS#33478 has been closed and the service will gain default dependencies with the next package. --Indigo (talk) 20:13, 6 April 2015 (UTC)

iptables-save vs iptables -L

I am the author of revision 402451, which Lahwaacz undid with the following reason:

Why isn't iptables-save the alternative? Its output is not
pretty-formatted, the immediately following note no longer applies and
the following uses iptables -L 

I strongly lobby for the use of iptables-save. The opposition indicated by Lahwaacz shows that there is disagreement regarding this matter.

The use ot `iptables-save` should be preferred to `iptables -L` and other variants of the command (`iptables -Ln`, `iptables -Lnv`).

The output of `iptables-save` is much nicer formatted than `iptables -L`. It produces output that is extremely similiar to the input format, shows the chain policies in a nice way, doesn't produce extremely long lines of text like `iptables -L`, does not try to resolve IPs to DNS names by default and shows all tables, hence the complete rule set, by default. Therefore `iptables-save` is vastly superior to `iptables -L`.

I do a lot of work in #netfilter on Freenode and newbies commonly assume that the output of `iptables -L` is the complete rule set. Also, the output is bad to read, because it does not conform to the input format, which makes debugging more difficult than necessary. #netfilter is the help channel regarding Linux firewalling and networking in general. It is the place people with Linux networking of firewalling problems go to get help.

Kind regards, Thermi