[KLUG Members] multicast

[Peter Buxton]

On Thu, Sep 04, 2003 at 10:53:44AM -0400, John Pesce was only escaped
   alone to tell thee:

> First off, thanks for the help.  I appreciate the help, but most of
> this is new to me and though I've read many of the howtos, saying
> something is easy doesn't help much ;( Can you possibly give an
> example or some syntax ?

You're welcome. It's below.

> I'm not sure what netfilter is. This is a fresh install of RH9 and
> this time I installed iptables because I want a firewall between my
> computers and the T1. My prior install did not have iptables and also
> passed non-multicast traffic between subnets .2 and .3 after setting
> ip_forward.

Netfilter is the greatest thing since sliced bread. It is also a source
of nefarious bugs. One Linux install at KLUG came to a stop when someone
chose the super-paranoid firewall setting and cut himself off from ALL
network traffic. ;-) 

www.netfilter.org is the greatest source of information on it.
Netfilter is the collection of kernel modules that mangle, drop,
forward, and otherwise manipulate network packets. It is what the
iptables* commands order and manipulate. Your kernel can have netfilter
if iptables is not installed, and vice versa.

> > > I need to forward pass the multicast traffic through the Linux box so 
> > > everyone can talk while running a firewall on the Linux box to protect my 
> > > two LANs from everything over the T1 except the multicast traffic.
> > 
> > That's easy.
> 
> That's what I like to hear. Please elaborate :)

> # Generated by iptables-save v1.2.7a on Thu Sep  4 09:59:25 2003
> *filter
> :INPUT ACCEPT [48344:40106261]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [41801:42967248]

If you enter `iptables-save -c`, you get a [packets:bytes] bracket
before each rule, letting you know how many times that rule has been
used. The default policy of FORWARD ACCEPT has not been hit at all. That
doesn't mean you haven't forwarded any packets.

Try this line:

iptables -I 1 RH-Lokkit-0-50-INPUT -m pkttype --pkt-type multicast -j ACCEPT

This will insert the allow multicast rule into the RH-Lokkit-0-50-INPUT
rule chain at the very start. Try `ping 224.0.0.1` and tell me what
hosts answer on the two LANs, if any.

If nothing else, you have to ensure that Netfilter isn't causing your
problem now:

-A RH-Lokkit-0-50-INPUT -p udp -m udp --dport 0:1023 -j REJECT --reject-with icmp-port-unreachable

Your current rule above blocks a lot of UDP ports and multicast is, for
now, a UDP-only protocol. The above ACCEPT command will dodge this
REJECT rule while leaving it otherwise intact.

The commands to drop all non-multicast traffic between you and 10.7.35.1
on eth1 is:

iptables -I 2 RH-Lokkit-0-50-INPUT -i eth1 -j DROP
iptables -I 3 RH-Lokkit-0-50-INPUT -o eth1 -j DROP

This is about as effective a firewall as you can get. ;-) If all three
iptables commands are given, the first line will match and accept
multicast traffic on any interface (remember, the first rule match exits
the rules chains).  The second and third will drop ANY other traffic to
or from 10.7.35.1.

HOWEVER, I highly recommend you don't add the last two commands yet. If
nothing else, setting up a PIM-DM daemon will be very hard if it is not
allowed to speak to its fellow router. Also, a real world firewall
should probably be a little more sophisticated: you'll probably need or
want to ping 10.7.35.1, or let it ping you, and these rules utterly
prevent that.

What do you see with the commands: `ip mroute show ; ip maddr show`?

> Sounds possible, though I don't know what transparent bridging is or how 
> to set it up. Any references?

True transparent bridging turns a Linux box into a glorified Ethernet
switch. You can forward packets using a machine with no IP numbers to
itself at all. This would be quite a change, but would almost certainly
work, EXCEPT: netfilter doesn't see packets in a bridge under the 2.4.x
kernel without a patch. RH, again, may offer this patch in their kernel,
but I don't know. Perhaps Adam does?

> > > 224.0.0.0      *            240.0.0.0      U    0     0     0 eth2
> > > 224.0.0.0      *            240.0.0.0      U    0     0     0 eth1
> > > 224.0.0.0      *            240.0.0.0      U    0     0     0 eth0
> 
> I sense that onlt the first is used. So how then do I tell it I mean to 
> talk to all the multicast machines over all the interfaces????

That is somewhat beyond the limits of linux route, and more in the
domain of a traffic router like mrouted, Zebra or pimd.

> I found a site talking about Zebra. I'm reading about it.

> > If you want to transform other packets and/or move them around, you
> > use netfilter.
> 
> So I need to make a tunnel between all my interfaces??
> Can I see an example please?
> Can I do that and still use iptables to firewall??

Well, no. I mean, wrong question. Apparently:

   GRE is a tunneling protocol that was originally developed by Cisco,
   and it can do a few more things than IP-in-IP tunneling. For example,
   you can also transport multicast traffic and IPv6 through a GRE
   tunnel.

    -- http://lartc.org/howto/lartc.tunnel.gre.html

So this might be an option to your 10.7.35.1 box, if they let you tunnel
GRE to it. But you haven't said if they do. Also, full ip tunneling is a
high-overhead solution. A dedicated pimd/Zebra/mrouted process would
probably be more efficient. See two below.

> <sigh> What do you suggest for a router daemon? What about netfilter, is 
> that part of iptables? How can I get it running with multicast 
> traffic while blocking everything else but incoming ssh??

Netfilter and ip route both have their uses, and are part of potential
solutions, but depending on exactly what your problem is, you may need
the full solution of a router daemon. See below.

> As I said above, 10.7.35.1 is the ethernet side of the T1 on my side that 
> is plugged into my rts's eth1. It also runs PIM-DM like everything else on 
> the other side of the T1. Anything destined for 10.7.* gets directed to 
> 10.7.35.1 and it deals with them.

You need to write down everything to do with 10.7.35.1:

1. Will it accept straight multicast packets, and forward them via 
   PIM-DM to the foreign networks, or

2. Does it (or its admins) expect you to speak *only* PIM-DM to it? (PIM
   sounds like it routes multicast packets by tunneling via standard IP 
   packets, and is not multicast itself.)

3. What other capabilities does it have available to you?

Questions 1 and 2 are very important. They define the problem you are
trying to solve:

If the answer is yes to #2, you may as well investigate the following
links:

http://netweb.usc.edu/pim/
http://www.antc.uoregon.edu/GATED/
http://www.antc.uoregon.edu/PIMDM/pimd-dense.html

These are all homepages of multicast router projects. Any of these might
work. Sadly, many of them require kernel patches, but for all we know,
Red Hat may have included them in their kernel (which differs
considerably from the stock 2.4.x kernel). I would recommend reviewing
your RPM list for some of these programs. If RH distributes them, then
they've probably included the patches in the RH kernel.

And let's face it: if you're going to need to run a PIM router daemon to
10.7.35.1 anyway, you may as well skip everything else and have it route
your multicast packets between your two LANs and use iptables to block
other traffic.

If, on the other hand, your answer is yes to 1, then we have other
options. For instance, what other services does rts provide besides
linking the two LANs and the T1? If the answer is 'None,' then perhaps
turning that box into a transparent bridge with firewalling is the
simplest solution.

-- 
-15
Rah! My re-tox weekend has been declared
a success! -- James Coates, 29 Oct 2001.