RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1147499 - RFE: use firewalld for dynamic firewal configuration
Summary: RFE: use firewalld for dynamic firewal configuration
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 7.2
Assignee: Michal Privoznik
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 969177
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-29 12:18 UTC by David Jaša
Modified: 2015-07-13 15:29 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of: 969177
Environment:
Last Closed: 2015-07-13 15:29:43 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description David Jaša 2014-09-29 12:18:10 UTC 
+++ This bug was initially created as a clone of Bug #969177 +++

Description of problem:
While libvirt has it's own powerfult firewall driver, it would be nice if it could play nicely with firewalld - use it's native interfaces to tell it to open a port when libvirt-managed VM starts listening on it and tell it to filter the port again when the port is not in use anymore.

Using firewalld means that other apps in need of dynamic port opening/closing means that they can ask for their ports, too, without any configuration races etc.

Version-Release number of selected component (if applicable):
1.0

+++ end clone +++


RHEL 7.1, libvirt version: libvirt-1.2.8-2


Addendum:
currently, there are at least these ranges used by qemu VMs:

grep 'port_m' /etc/libvirt/qemu.conf
#remote_display_port_min = 5900
#remote_display_port_max = 65535
#remote_websocket_port_min = 5700
#remote_websocket_port_max = 65535
#migration_port_min = 49152
#migration_port_max = 49215

It would be cool for libvirt not to need to have wide subsets of these ranges opened in order to fully function but instead have firewalld do this job in the runtime
Comment 1 Michal Privoznik 2015-07-13 15:29:43 UTC 
(In reply to David Jaša from comment #0)
> +++ This bug was initially created as a clone of Bug #969177 +++
> 
> Description of problem:
> While libvirt has it's own powerfult firewall driver, it would be nice if it
> could play nicely with firewalld - use it's native interfaces to tell it to
> open a port when libvirt-managed VM starts listening on it and tell it to
> filter the port again when the port is not in use anymore.
> 
> Using firewalld means that other apps in need of dynamic port
> opening/closing means that they can ask for their ports, too, without any
> configuration races etc.

I am afraid this is not feasible. I mean, this kind of requests often pops up on the upstream list and we reject it immediatelly. You certainly don't want a deamon on your host opening a random ports in your firewall. It crosses the purpose of the firewall, which is - even if one runs a buggy application (e.g. a backdoor), which opens random ports, attacker is unable to connect as long as a box in the middle don't let the connection through. In this case, the box is - you guessed it - a firewall.

> 
> Version-Release number of selected component (if applicable):
> 1.0
> 
> +++ end clone +++
> 
> 
> RHEL 7.1, libvirt version: libvirt-1.2.8-2
> 
> 
> Addendum:
> currently, there are at least these ranges used by qemu VMs:
> 
> grep 'port_m' /etc/libvirt/qemu.conf
> #remote_display_port_min = 5900
> #remote_display_port_max = 65535
> #remote_websocket_port_min = 5700
> #remote_websocket_port_max = 65535
> #migration_port_min = 49152
> #migration_port_max = 49215
> 
> It would be cool for libvirt not to need to have wide subsets of these
> ranges opened in order to fully function but instead have firewalld do this
> job in the runtime

The idea to make these ranges configurable was to allow sysadmins choose the shortest range needed.
Note You need to log in before you can comment on or make changes to this bug.