Greetings,
One of my biggest frustrations with CentOS 7 has been firewalld.
Essentially all of the documentation just flat doesn't work.
One common thing that needs to be done is to change the zone of an interface, however I've tried:
firewall-cmd --permanent --zone=internal --change-interface=ens192 firewall-cmd --permanent --zone=internal --add-interface=ens192
I've also tried setting in /etc/sysconfig/network-scripts/ifcfg-ens192:
ZONE=internal ZONE="internal"
No matter what, when firewalld starts, ens192 will be in the public zone.
What am I doing wrong? Why does the documented command structure not work?
On 11/6/2015 1:31 PM, Nick Bright wrote:
One of my biggest frustrations with CentOS 7 has been firewalld.
Essentially all of the documentation just flat doesn't work.
One common thing that needs to be done is to change the zone of an interface, however I've tried:
firewall-cmd --permanent --zone=internal --change-interface=ens192 firewall-cmd --permanent --zone=internal --add-interface=ens192
I've also tried setting in /etc/sysconfig/network-scripts/ifcfg-ens192:
ZONE=internal ZONE="internal"
No matter what, when firewalld starts, ens192 will be in the public zone.
What am I doing wrong? Why does the documented command structure not work?
I haven't messed with firewalld yet, so the following is purely conjecture...
does
firewall-cmd --get-zones
list this "internal" zone ? if not, you may need to create it first,
firewall-cmd --permanent --new-zone=internal firewall-cmd --reload
THEN assign your interface to it,
firewall-cmd --permanent --zone=internal --change-interface=ens192
On Nov 6, 2015 3:31 PM, "Nick Bright" nick.bright@valnet.net wrote:
Greetings,
One of my biggest frustrations with CentOS 7 has been firewalld.
Essentially all of the documentation just flat doesn't work.
One common thing that needs to be done is to change the zone of an
interface, however I've tried:
firewall-cmd --permanent --zone=internal --change-interface=ens192 firewall-cmd --permanent --zone=internal --add-interface=ens192
I've also tried setting in /etc/sysconfig/network-scripts/ifcfg-ens192:
ZONE=internal ZONE="internal"
No matter what, when firewalld starts, ens192 will be in the public zone.
What am I doing wrong? Why does the documented command structure not work?
--
- Nick Bright -
Firewalld does physical interfaces, NetworkManager has profiles on top of them. NM can specify a zone and communicate it to firewalld - which should work from your ifcfg edit - but the reverse currently doesn't happen. Try with nmcli:
nmcli con modify ens19p0 connection.zone internal
...btw, the insertion of the 'p' was deliberate, I've seen more device names of that form. doublecheck your device name too.
--Pete
On 6 November 2015 at 21:49, Pete Travis lists@petetravis.com wrote:
On Nov 6, 2015 3:31 PM, "Nick Bright" nick.bright@valnet.net wrote:
Greetings,
One of my biggest frustrations with CentOS 7 has been firewalld.
Essentially all of the documentation just flat doesn't work.
One common thing that needs to be done is to change the zone of an
interface, however I've tried:
firewall-cmd --permanent --zone=internal --change-interface=ens192 firewall-cmd --permanent --zone=internal --add-interface=ens192
I've also tried setting in /etc/sysconfig/network-scripts/ifcfg-ens192:
ZONE=internal ZONE="internal"
No matter what, when firewalld starts, ens192 will be in the public zone.
What am I doing wrong? Why does the documented command structure not work?
--
- Nick Bright -
Firewalld does physical interfaces, NetworkManager has profiles on top of them. NM can specify a zone and communicate it to firewalld - which should work from your ifcfg edit - but the reverse currently doesn't happen. Try with nmcli:
nmcli con modify ens19p0 connection.zone internal
...btw, the insertion of the 'p' was deliberate, I've seen more device names of that form. doublecheck your device name too.
I have a couple of relevant articles you may be interested in ...
On assigning the zone via NM: https://www.hogarthuk.com/?q=node/8
Look down to the "Specifying a particular firewall zone" bit ... remember that if you edit the files rather than using nmcli you must reload NM (or do nmcli reload) for that to take effect.
If you specify a zone in NM then this will override the firewalld configuration if the zone is specified there.
Here's some firewalld stuff: https://www.hogarthuk.com/?q=node/9
Don't forget that if you use --permanent on a command you need to do a reload for it to read the config from disk and apply it.
On 11/6/2015 3:58 PM, James Hogarth wrote:
I have a couple of relevant articles you may be interested in ...
On assigning the zone via NM: https://www.hogarthuk.com/?q=node/8
Look down to the "Specifying a particular firewall zone" bit ... remember that if you edit the files rather than using nmcli you must reload NM (or do nmcli reload) for that to take effect.
If you specify a zone in NM then this will override the firewalld configuration if the zone is specified there.
Here's some firewalld stuff: https://www.hogarthuk.com/?q=node/9
Don't forget that if you use --permanent on a command you need to do a reload for it to read the config from disk and apply it.
Thanks for the articles, they're informative.
Here's what's really irritating me though.
firewall-cmd --zone=internal --change-interface=ens224 --permanent
^^ This command results in NO ACTION TAKEN. The zone IS NOT CHANGED.
firewall-cmd --zone=internal --change-interface=ens224
This command results in the zone of ens224 being changed to internal, as desired. Of course, this is not permanent.
As such, firewall-cmd --reload (or a reboot, ect) will revert to the public zone. To save the change, one must execute firewall-cmd --runtime-to-permanent.
This is very frustrating, and not obvious. If --permanent doesn't work for a command, then it should give an error - not silently fail without doing anything!
On 11/16/2015 01:39 PM, Nick Bright wrote:
This is very frustrating, and not obvious. If --permanent doesn't work for a command, then it should give an error - not silently fail without doing anything!
But --permanent *did* work.
What you're seeing is the documented behavior: --permanent The permanent option --permanent can be used to set options permanently. These changes are not effective immediately, only after service restart/reload or system reboot. Without the --permanent option, a change will only be part of the runtime configuration.
If you want to make a change in runtime and permanent configuration, use the same call with and without the --permanent option.
On 16.11.2015 22:58, Gordon Messmer wrote:
On 11/16/2015 01:39 PM, Nick Bright wrote:
This is very frustrating, and not obvious. If --permanent doesn't work for a command, then it should give an error - not silently fail without doing anything!
But --permanent *did* work.
What you're seeing is the documented behavior: --permanent The permanent option --permanent can be used to set options permanently. These changes are not effective immediately, only after service restart/reload or system reboot. Without the --permanent option, a change will only be part of the runtime configuration.
If you want to make a change in runtime and permanent configuration, use the same call with and without the--permanent option.
That's fairly annoying behavior as it creates the potential for accidentally diverging configurations. Why not do the same as virsh an have two options for this? When I attach a device I can specify --config to update the persistent configuration, --live to update the runtime configuration and both if I want to change both. That's a much better API in my opinion.
Regards, Dennis
Em 17-11-2015 01:26, Dennis Jacobfeuerborn escreveu:
On 16.11.2015 22:58, Gordon Messmer wrote:
On 11/16/2015 01:39 PM, Nick Bright wrote:
This is very frustrating, and not obvious. If --permanent doesn't work for a command, then it should give an error - not silently fail without doing anything!
But --permanent *did* work.
What you're seeing is the documented behavior: --permanent The permanent option --permanent can be used to set options permanently. These changes are not effective immediately, only after service restart/reload or system reboot. Without the --permanent option, a change will only be part of the runtime configuration.
If you want to make a change in runtime and permanent configuration, use the same call with and without the--permanent option.
That's fairly annoying behavior as it creates the potential for accidentally diverging configurations. Why not do the same as virsh an have two options for this? When I attach a device I can specify --config to update the persistent configuration, --live to update the runtime configuration and both if I want to change both. That's a much better API in my opinion.
It's the same thing but with different names and a default, --config. And I agree, it would be nice to be able to issue both options at once. Would you open a BZ asking for this or should I?
Marcelo
On 11/16/2015 3:58 PM, Gordon Messmer wrote:
On 11/16/2015 01:39 PM, Nick Bright wrote:
This is very frustrating, and not obvious. If --permanent doesn't work for a command, then it should give an error - not silently fail without doing anything!
But --permanent *did* work.
No, it didn't. Not for changing the zone.
After using --permanent, and restarting the firewall, _the zone was not changed_. I've duplicated this behavior on a half dozen installs now.
https://bugzilla.redhat.com/show_bug.cgi?id=1112742
-
Dennis Jacobfeuerborn -
Gordon Messmer -
Ian Pilcher -
James Hogarth -
John R Pierce -
Marcelo Ricardo Leitner -
Nick Bright -
Pete Travis