Bug 1271815 - The stock FirewallD rules should not block IGMP
The stock FirewallD rules should not block IGMP
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: firewalld (Show other bugs)
7.1
Unspecified Linux
medium Severity high
: rc
: ---
Assigned To: Eric Garver
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-14 15:37 EDT by Warren Young
Modified: 2017-09-08 09:51 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-09-08 09:51:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Warren Young 2015-10-14 15:37:21 EDT
Description of problem:

On a network with correctly-configured IGMP snooping switches, long-term IGMP streams being received by the Linux box will stop after the IGMP querier stops receiving IGMP group membership query responses from the Linux kernel, since it believes the receiver has disappeared.

IGMP packets should never be blocked at the firewall for the same sort of reason that ICMP packets should not be blocked. Doing so basically breaks multicast networking.


Simple fix:

The default setup for FirewallD should do something like this:

firewall-cmd --direct --add-rule --permanent ipv4 filter INPUT 0 -p igmp -j ACCEPT


How reproducible:

You need an IGMP source that sends continuously over some longish period, an IGMP receiver for that source, and an IGMP-aware network. Our application is IPTV, which you can simulate using a pair of VLC instances, one multicasting a movie file to the other.

I regret the need to recommend third-party software to demonstrate the problem, but I just don't know of any software built into RHEL with similar characteristics. The closest thing I can think of is Avahi, but its multicast conversations are very short, so they can't run into this problem.

If you're going to use VLC to demonstrate the problem, you need to choose a movie file that is longer than your network switch's IGMP group membership timeout, which is specific to the switch. 10 minutes is typical, but not standardized anywhere as far as I know.


Additional info:

If you are reading this and wondering why you're just now hearing about this in 2015, there are a bunch of reasons:

0. RHEL/Fedora didn't always block IGMP in the firewall, or didn't always turn the firewall on by default.

1. Multicast networking never has been super-popular, so any problem in this area will affect only a small minority of users.

2. This specific problem won't affect any multicast stream that starts and stops within the timeout imposed by an IGMP-aware switch. (e.g. Avahi.)

3. Low-end Ethernet switches aren't IGMP-aware, and the higher-end ones that do have such features universally ship with those features disabled, in my experience. Either way, multicast on such a network turns into broadcast at the switch, which avoids this problem entirely. Only networks managed by people who care about multicast efficiency will use IGMP-aware switches, and will have IGMP snooping and querying enabled.
Comment 2 Warren Young 2015-10-14 17:06:29 EDT
On reading back through this, I realize that there is a key fact never quite stated here: The core problem is that the deny-by-default stock FirewallD rules don't contain an exception for IGMP, as they do for ICMP. The firewall blocks the IGMP group membership queries from the upstream network switch or multicast router, so the kernel's network stack never realizes it should be telling the IGMP querier that it is still interested in the multicast stream because the program that asked for it is still running.

A close analogy would be if the firewall were dropping TCP keepalive packets. The TCP connection would be established, and it would transfer data for some time, but eventually the peer's network stack would time out because it wasn't getting replies to its keepalive probes.
Comment 3 Tomas Dolezal 2016-05-24 12:26:07 EDT
while it's not a default, since v0.4.0+ you can simply enable IGMP in any zone (runtime and/or permanent) using this command:

# firewall-cmd --add-protocol igmp

this adds rule for current zone:
-A IN_public_allow -p igmp -m conntrack --ctstate NEW -j ACCEPT

rebase bug 1302802
Comment 4 Thomas Woerner 2016-06-01 07:27:12 EDT
(In reply to Warren Young from comment #0)
> Description of problem:
> 
> On a network with correctly-configured IGMP snooping switches, long-term
> IGMP streams being received by the Linux box will stop after the IGMP
> querier stops receiving IGMP group membership query responses from the Linux
> kernel, since it believes the receiver has disappeared.
> 
> IGMP packets should never be blocked at the firewall for the same sort of
> reason that ICMP packets should not be blocked. Doing so basically breaks
> multicast networking.
> 
> 
> Simple fix:
> 
> The default setup for FirewallD should do something like this:
> 
> firewall-cmd --direct --add-rule --permanent ipv4 filter INPUT 0 -p igmp -j
> ACCEPT
> 
> 
> How reproducible:
> 
> You need an IGMP source that sends continuously over some longish period, an
> IGMP receiver for that source, and an IGMP-aware network. Our application is
> IPTV, which you can simulate using a pair of VLC instances, one multicasting
> a movie file to the other.
> 
> I regret the need to recommend third-party software to demonstrate the
> problem, but I just don't know of any software built into RHEL with similar
> characteristics. The closest thing I can think of is Avahi, but its
> multicast conversations are very short, so they can't run into this problem.
> 
> If you're going to use VLC to demonstrate the problem, you need to choose a
> movie file that is longer than your network switch's IGMP group membership
> timeout, which is specific to the switch. 10 minutes is typical, but not
> standardized anywhere as far as I know.
> 
> 
> Additional info:
> 
> If you are reading this and wondering why you're just now hearing about this
> in 2015, there are a bunch of reasons:
> 
> 0. RHEL/Fedora didn't always block IGMP in the firewall, or didn't always
> turn the firewall on by default.
> 
IGMP was always dropped in the firewall configuration. Traditionally the firewall has always been enabled. But the firewall could be disabled at installation time. For cloud images the firewall is disabled, but I do not think that this is used in your environment.

> 1. Multicast networking never has been super-popular, so any problem in this
> area will affect only a small minority of users.
> 
IGMP is a special case in my opinion that should not be allowed per default.

> 2. This specific problem won't affect any multicast stream that starts and
> stops within the timeout imposed by an IGMP-aware switch. (e.g. Avahi.)
> 
> 3. Low-end Ethernet switches aren't IGMP-aware, and the higher-end ones that
> do have such features universally ship with those features disabled, in my
> experience. Either way, multicast on such a network turns into broadcast at
> the switch, which avoids this problem entirely. Only networks managed by
> people who care about multicast efficiency will use IGMP-aware switches, and
> will have IGMP snooping and querying enabled.
I do not think that the firewall should allow IGMP as it is not enabled in switches per default.

With firewalld-0.4.0 and up you can simply allow IGMP traffic in a zone (see comment #3).
Comment 5 Thomas Woerner 2016-06-01 07:28:35 EDT
It is planned to have a new version of firewalld in RHEL-7.3.
Comment 6 Warren Young 2016-06-01 18:14:37 EDT
> IGMP is a special case in my opinion that should not be allowed per default.

Multicasting will continue to be the red-headed stepchild of the TCP/IP world as long as this attitude lasts.

Blocking all multicasting by default is just as wrong as blocking all IGMP or all broadcasting. The block-by-default nature of the stock firewall should be limited to blocking the UDP ports, so that individual services can un-block themselves. You don't want competing RPM %post scripts enabling and disabling IGMP as a whole, any more than you'd want them enabling or disabling TCP or any other protocol used by many different programs.

> I do not think that the firewall should allow IGMP as it is not enabled in
> switches per default.

You mean that IGMP *snooping* is not enabled in switches by default, but that is not the same thing as IGMP being blocked in switches. With IGMP snooping disabled, switches effectively turn multicast into broadcast. Thus, switches pass multicast even without any special IGMP awareness, a fact you can verify by buying the cheapest network switch available to you; multicasting still works, even though the switch hasn't the slightest clue about IGMP, being a purely layer 2 device.

The only thing IGMP awareness does in a switch is let it be more intelligent about parcelling multicast packets out to its ports. That is a good thing, but it is irrelevant to the discussion here.
Comment 9 Eric Garver 2017-09-08 09:51:46 EDT
It's debatable whether blocking IGMP by default is a good thing or not. The current and past default is to block. I don't think changing the defaults without a solid reason is a good idea. Enabling IGMP is a one liner:

  # firewall-cmd --add-protocol igmp

If in the future we have a good reason that IGMP should be enabled by default then we can revisit this BZ.

Note You need to log in before you can comment on or make changes to this bug.