Description of problem: I have two machines in a JBoss cluster that communicate via multicast. I want to temporarily take one out of rotation with the following rules: /sbin/iptables -A INPUT -m pkttype --pkt-type multicast -j DROP /sbin/iptables -A OUTPUT -m pkttype --pkt-type multicast -j DROP The rule for the INPUT chain works. The rule on the OUTPUT chain still allows multicast packets to leave the system. I tried setting it to log and it does not work either. Version-Release number of selected component (if applicable): iptables-1.3.5-4.el5 kernel-2.6.18-128.7.1.el5 How reproducible: I am using the following scripts to send multicast packets between the two systems: (taken from http://onestepback.org/index.cgi/Tech/Ruby/MulticastingInRuby.red) send.rb: --------------- require 'socket' MULTICAST_ADDR = "225.4.5.6" PORT= 5000 begin socket = UDPSocket.open socket.setsockopt(Socket::IPPROTO_IP, Socket::IP_TTL, [1].pack('i')) socket.send(ARGV.join(' '), 0, MULTICAST_ADDR, PORT) ensure socket.close end receive.rb: ------------------- require 'socket' require 'ipaddr' MULTICAST_ADDR = "225.4.5.6" PORT = 5000 ip = IPAddr.new(MULTICAST_ADDR).hton + IPAddr.new("0.0.0.0").hton sock = UDPSocket.new sock.setsockopt(Socket::IPPROTO_IP, Socket::IP_ADD_MEMBERSHIP, ip) sock.bind(Socket::INADDR_ANY, PORT) loop do msg, info = sock.recvfrom(1024) puts "MSG: #{msg} from #{info[2]} (#{info[3]})/#{info[1]} len #{msg.size}" end Steps to Reproduce: 1. service iptables stop (on both systems) 2. Add the two pkttype firewall rules to one of the systems 3. run receive.rb on one system 4. run send.rb on the other Actual results: The packets are sent and received just fine. If I add the rules to the other system the inbound packets will be dropped as expected. Expected results: EPERM should be returned to the script when the kernel drops the outbound packets. The other system should not receive the multicast packet Additional info: To workaround this issue I am using: /sbin/iptables -A CLUSTER_IN -d 224.0.0.0/4 -j DROP /sbin/iptables -A CLUSTER_OUT -d 224.0.0.0/4 -j DROP
The pkttype match is a match on the link level (i.e. MAC) address type, see man iptables output: pkttype This module matches the link-layer packet type. For outbound packets, the link layer (and hence MAC address) haven't been constructed when the packet is in netfilter (to see this, log an inbound packet and also an outbound packet and see that there is no MAC= output for the outbound packet, whereas there is for the inbound packet). The output of: # iptables -m pkttype --help gives: pkttype match options: [!] --pkt-type packettype match packet type Valid packet types: unicast to us broadcast to all multicast to group Although not explicitly stated, in can be deduced from the unicast line that it is for inbound packets. To match on address type for outbound packets, use the addrtype match, i.e. -m addrtype --dst-type MULTICAST This can also be used for inbound packets with -m addrtype --src-type MULTICAST. The addrtype match appears to allow more control in general than the pkttype match. So in your case you could have: /sbin/iptables -A CLUSTER_IN -m addrtype --dst-type MULTICAST -j DROP /sbin/iptables -A CLUSTER_OUT -m addrtype --src-type MULTICAST -j DROP
Apologies, there is an error in the final examples above. They should read: /sbin/iptables -A CLUSTER_IN -m addrtype --dst-type MULTICAST -j DROP /sbin/iptables -A CLUSTER_OUT -m addrtype --dst-type MULTICAST -j DROP i.e. look at the dst-type for both inbound and outbound.
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).