Default firewall solution in F17 will most likely [1] be FirewallD [2]. It adds a model called 'network zones' [3] which is basically a trust level for a network connection. This 'zone' could be changed (default zone is called 'public' and it's mostly untrusted) for example in NetworkManager applet (this GUI part is still not done atm I think) and NM stores [4] this information into /etc/sysconfig/network-scripts/ifcfg-<iface> as ZONE=<zone>. Every time NM starts an interface it tells firewalld which zone the interface belongs to and when the connection gets down the firewalld is also informed about that. But because there have been people (including me) who have still been using 'network' service instead of NM it would be good if initscripts could do the same and inform firewalld about zones the interfaces belong to. I see I just missed the 9.35 release so this probably won't make it into F17, will it ? [1] https://fedorahosted.org/fesco/ticket/805 [2] https://fedoraproject.org/wiki/Features/DynamicFirewall [3] https://fedoraproject.org/wiki/FirewallD/#Network_zones:_Network_security_model [4] http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=3e11682ddc69037a06a9bd70abf2739eb43e9876
Created attachment 569403 [details] patch
Why do we need to inform the firewall about devices coming and going - it doesn't listen on netlink?
No, firewalld does not listen on netlink. If NM is in use, it will tell firewalld to add an interface to a zone and to remove it also later on again. NM is providing the information needed by firewalld - also the zone to use, because NM knows about the connection. The plan here is to select a zone by environment (gateway, router, ..) also for wired connections in the future. If NM is not in use, firewalld does not know about connections and interfaces.
Well, it would probably be possible for firewalld to itself monitor when interfaces are getting up and down. But the information to which zone the interface belongs is a property of the connection, stored in /etc/sysconfig/network-scripts/ifcfg-<iface> and firewalld itself doesn't store it anywhere. So for getting this information firewalld would need to obtain the value for ZONE key from ifcfg-<iface>. And to me it seems cleaner when only NetworkManager and initscripts access these ifcfg-<iface> files.
Agreed on that regard. However, I do want to confirm: - device eth0 brought up in Zone 1 - firewalld is called to specify this - device eth0 goes down, firewalld is not called for some reason - device eth0 brought up in Zone 2 - firewalld is called to specify this Does the right thing happen in firewalld in this case?
Depends on what the 'right thing' means ;-) firewalld doesn't allow to add interface to another zone if it has been in one already. So after you steps the interface will still be in Zone 1. However there's also changeZone() [1] method which changes zone of interface to specified zone regardless of what zone it has been previously. It actually removes interface from whatever zone it has been and adds to specified zone. If the interface has not been part of any zone then it works the same as addInterface() so we could possibly use firewall-cmd --zone=${ZONE} --change --interface=${DEVICE} > /dev/null 2>&1 instead of firewall-cmd --zone=${ZONE} --add --interface=${DEVICE} > /dev/null 2>&1 That should solve the problem. [1] http://git.fedorahosted.org/git/?p=firewalld.git;a=commitdiff;h=61ff98f546b9c4211d8ec38be3b21df0a668ff80
Added as http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=bf931d4f660af978eef8652ad275fcb7bab0e749 with the following changes: 1) s/add/change/ as mentioned above 2) the firewall poking is done in ifup-post/ifdown-post, to catch more than just ethernet connection types
initscripts-9.37-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/FEDORA-2012-3654/initscripts-9.37-1.fc17
Package initscripts-9.37-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing initscripts-9.37-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-3654/initscripts-9.37-1.fc17 then log in and leave karma (feedback).
initscripts-9.37-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #7) > 2) the firewall poking is done in ifup-post/ifdown-post, to catch more than > just ethernet connection types The 'firewall poking' had in my original patch been done in ifup-eth before calling of dhcpv6 client, because dhcpv6 client needs open port to get answers from server. But now the dhcpv6 client doesn't get any answer from server because the correct port is not open at the time when dhcpv6 client starts. The port is opened once the interface is added to a zone, i.e. in ifup-post. I have one very nice solution, the "-nw" (nowait) option pro dhclient. From dhclient(8): -nw Become a daemon immediately (nowait) rather than waiting until an an IP address has been acquired. So if we change ifup-eth like this: - /sbin/dhclient -6 -1 ${DHCPV6C_OPTIONS} ... + /sbin/dhclient -6 -1 -nw ${DHCPV6C_OPTIONS} ... the 'dhclient -6' will be started in background, ifup-post then adds the interface to a zone, which makes the hole for dhcpv6-client in firewall and the 'dhclient -6' (still running in background) will finally get answer and configure the interface with IPv6 address. happy end :-) Moreover this solves the problem I've seen earlier when ifup was blocking initialization for a minute when there's DHCPV6C=yes in ifcfg-<iface> but no running dhcpv6 server. What do you think ?
(In reply to comment #11) > What do you think ? Firewall poking should not be required for DHCP to work, period. IPv6 shouldn't be different from IPv4 in this regard.
DHCP for IPv4 doesn't need firewall poking because it uses raw sockets thus sidestepping firewall completely.
Bill, could you think about this (in my opinion) harmless change once more ? ifup-eth: - /sbin/dhclient -6 -1 ${DHCPV6C_OPTIONS} ... + /sbin/dhclient -6 -1 -nw ${DHCPV6C_OPTIONS} ... (In reply to comment #12) > Firewall poking should not be required for DHCP to work, period. The fact that DHCPv4 does not need firewall poking is not a design decision but side-effect of using raw sockets. From [1]: ... dhcp uses raw sockets to be able to transmit to and receive packets sent to the all-ones limited broadcast address (255.255.255.255), and being able to send a unicast without an ARP ... ... dhcpd's raw sockets receive packets before the point at which most OS packet filters and firewalls operate ... > IPv6 shouldn't be different from IPv4 in this regard. DHCPv6 is completely different protocol which does not need to use these hacks (raw sockets), it can use classic BSD/UDP sockets (also thanks to ipv6 link-local addresses autoconfiguration) and therefore every common firewall blocks DHCPv6 messages unless explicitly allowed. [1] https://deepthought.isc.org/article/AA-00378/0/Why-does-DHCP-use-raw-sockets.html
While backgrounding the daemon will allow it to work via this mechanism, it breaks the synchronous paradigm of ifup, where it doesn't exit unless the interface is configured. Arguably the dhclient -6 code should be checking for an error as well.
Modified to just poke it twice (before ifup-ipv6 and the catch-all in ifup-post); should be harmless.
initscripts-9.42.1-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/initscripts-9.42.1-1.fc18
Package initscripts-9.42.1-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing initscripts-9.42.1-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-19994/initscripts-9.42.1-1.fc18 then log in and leave karma (feedback).
initscripts-9.42.1-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.