[KLUG Members] multicast

[John Pesce]

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 ?

I have more comments below with the prior remarks, but here is my 
iptables-save as requested. I don't see anything to explain how my 
non-multicast packets are getting from subnet .2 to subnet .3 other then 
that I set ip_forward and rts knows a route to both subnets. rts by the 
way is the linux box sitting between the two subnets. And yes, the Cisco 
sitting on my end of the T1 that is plugged into rts's eth1 has IP 
10.7.35.1 and also has PIM-DM. rts's eth1 has IP 10.7.35.2

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.


# 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]
:RH-Lokkit-0-50-INPUT - [0:0]
-A INPUT -j RH-Lokkit-0-50-INPUT
-A FORWARD -j RH-Lokkit-0-50-INPUT
-A RH-Lokkit-0-50-INPUT -s 192.168.2.1 -p udp -m udp --sport 53 --dport 1025:65535 -j ACCEPT
-A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
-A RH-Lokkit-0-50-INPUT -i eth0 -p udp -m udp --sport 67:68 --dport 67:68 -j ACCEPT
-A RH-Lokkit-0-50-INPUT -i eth1 -p udp -m udp --sport 67:68 --dport 67:68 -j ACCEPT
-A RH-Lokkit-0-50-INPUT -i lo -j ACCEPT
-A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 0:1023 --tcp-flags SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable
-A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 2049 --tcp-flags SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable
-A RH-Lokkit-0-50-INPUT -p udp -m udp --dport 0:1023 -j REJECT --reject-with icmp-port-unreachable
-A RH-Lokkit-0-50-INPUT -p udp -m udp --dport 2049 -j REJECT --reject-with icmp-port-unreachable
-A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 6000:6009 --tcp-flags SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable
-A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 7100 --tcp-flags SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable
COMMIT


more is below.

Thanks,
John


On Thu, 4 Sep 2003, Peter Buxton wrote:

> Adam Williams said:
> 
> > Yep, you have to have a userspace daemon to establish the tunnels over
> > the non-multicasting routers.  We use zebra for OSPF and OSPF
> > propogation into RIP.  I really like Zebra, and the configuration and
> > management is extremely Cisco like.  Most distro's provide a package
> > of Zebra.

I found a site talking about Zebra. I'm reading about it.
 
> Okay, but so far no one has admitted to using any of these userspace
> daemons. ;-) I think that is our dilemma.
> 
> We have three options:
> 
> 1. Transparent bridging. Since this works at the Ethernet level,
>    Multicast/IGMP is a no-brainer -- ALL packets will be forwarded. This
>    may work if Pesce's foreign side has no rules against multicast
>    traffic, as it is just UDP/IP packets with a reserved IP address. It
>    will definitely work for Pesce's two LANs and Rusty Yonker's four
>    LANs.

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

> On Wed, Sep 03, 2003 at 05:20:51PM -0400, John Pesce was only escaped
>    alone to tell thee:
> 
> > If I ping -c 2 224.0.0.1 I only get responses from machines on eth2.
> 
> No wonder:
> 
> > 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
> 
> What comes first, eh? eth2. Guess where all the packets go?


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????

 
> See? Not hard at all. I suspected this in my last post.  See, 'route' or
> 'ip route' ONLY affects your Linux box's own outgoing packets. ip is a

Really? This is news to me, I must have read something wrong again. darn.


> little more sophisticated, and possesses an ip tunnel facility, but it
> doesn't mangle packets.  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??


> ip_forward does NOT turn on any routing or packet filtering. If your
> Linux box is passing IP packets, netfilter is involved. What are your
> rules?

hmmm. My rules are above. Again, I seem be be clueless about netfilter.


> 10.7.31.0      10.7.35.1      255.255.255.0   UG    0     0     0 eth1
> 10.7.36.0      10.7.35.1      255.255.255.0   UG    0     0     0 eth1
> 10.7.32.0      10.7.35.1      255.255.255.0   UG    0     0     0 eth1
> 10.7.33.0      10.7.35.1      255.255.255.0   UG    0     0     0 eth1
> 10.7.34.0      10.7.35.1      255.255.255.0   UG    0     0     0 eth1
> 10.7.35.0      *              255.255.255.0   U     0     0     0 eth1
> 
> > On the other side of the T1 are more T1s connecting serveral LANs. All
> > the T1 routers have PIM-DM turned on.
> 
> But not 10.7.35.1? What do you know about it?

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.
 
> If they're speaking PIM-DM over there, you need to speak it over here.
> You need the address of one or more boxes on their side that are allowed
> to pass mcast traffic to an mcast router on your network.

The other end of the T1 is at a site acting as a hub for the other sites. 
There are IP tunnels on the other side of the T1 routing traffic to the 
other sites.
 
> > 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 :)

 
> > I looked at the kernel config on my RH9 install and multicast
> > forwarding is enabled by default. I just need to know how to get the
> > multicast flowing through the firewall.
> 
> The kernel capability of multicast forwarding is indeed installed,
> probably as a kernel module, on rts. But you won't be forwarding
> anything with that module until you install a router daemon with
> multicast capability to use that module.
> 
> Or, you can use netfilter to solve some of that problem.

<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??

Please be patient. 

Thanks,
John