troglobit / mrouted

The original DVMRP (dynamic multicast routing) implementation for UNIX
https://troglobit.com/projects/mrouted/
Other
83 stars 17 forks source link

mrouted receives igmp join but doesn't route #41

Closed lucdig closed 3 years ago

lucdig commented 4 years ago

Hi, I'm testing multicast routing because I have a camera at home that is able to generate an rtp multicast flow. I want to implement a secure system to route the rtp flow only on ssh-tap interfaces.

I set the camera to use 239.255.42.42:5004. The camera sends the rtp flow to the eth1 of my debian_home0 pc.

The debian_home0 pc has an ssh-tap0 interface to a public_server. I use smcroute to route the rtp flow --> tap0 --> public_server. The public_server receives the rtp flow correctly through tap0.

The public_server has mrouted installed, and another ssh-tap1 interface with debian_home1 (debian_home1 is, for testing, a virtual machine).

debian_home0 <-- tap0 --> public_server <-- tap1 --> debian_home1

/etc/mrouted.conf in public_server is: name CAMERA 239.255.42.42/32 phyint vio0 disable # don't route multicast to the ethernet

public_server is an OpenBSD where I set: net.inet.ip.mforwarding=1 multicast=YES in /etc/rc.conf

debian_home1 has smcroutectl installed. On debian_home1, I run the command: smcroutectl join tap1 239.255.42.42

I see, in the public_server, the igmp-join coming through the tap1 interface. I expect to receive the rtp flow through tap1, but, I don't know why, debian_home1 doesn't receive it.

Am I missing anything? It seems that mrouted on the OpenBSD public_server is not working properly.

Regards, thanks a lot

troglobit commented 4 years ago
  1. Tap interfaces are layer 2
  2. Both mrouted and SMCRoute act on layer 3
  3. Have you checked the TTL?
lucdig commented 3 years ago

Hi, I've changed the ssh interfaces to tun (layer 3). debian_home0 <-- tun0 --> public_server <-- tun1 --> debian_home1

The TTL of the stream is 29, this is a tcpdump of tun0 made on public_server OpenBSD: 10:24:48.408795 10.10.10.2.5004 > 239.255.42.42.5004: udp 1316 (ttl 29, id 26235, len 1344)

When I run smcroutectl join tun1 239.255.42.42 on debian_home1, this is the output of tcpdump -e -v -n -i tun1 on public_server: 10:27:33.911255 10.201.201.1 > 239.255.42.42: igmp nreport 239.255.42.42 (DF) [tos 0xc0] [ttl 1] (id 0, len 32, optlen=4 IPOPT-148{4})

The result is the same, I see no multicast traffic on tun1 after the join :-(

troglobit commented 3 years ago

Ah, now I wee what's going on! (It helps to read the whole text :)

I'm not the maintainer of the mrouted package in OpenBSD. You should report the issue with the OpenBSD folk. Or try to build my (much updated) version of mrouted for OpenBSD. I haven't tested that in ages, so you may run into minor porting issues. It does however build for FreeBSD, so it should work also on OpenBSD.

lucdig commented 3 years ago

Hi, I achieved to build your mrouted for OpenBSD.

I replicated the scenario, but the result is the same. :-(

Thanks anyway, regards

troglobit commented 3 years ago

Was the MULTICAST interface flag set on the tun interfaces? Otherwise mrouted cannot use them.

lucdig commented 3 years ago

Yes. In OpenBSD

# ifconfig tun2
tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
        index 6 priority 0 llprio 3
        groups: tun
        status: active
        inet 10.202.202.2 --> 10.202.202.1 netmask 0xfffffffc
troglobit commented 3 years ago

Weird. Well what does mroutectl say? (Many commands available for debugging)

lucdig commented 3 years ago

I reviewed the configurations, and I have achieved something that works, thanks.

/etc/mrouted.conf is:

# cat /etc/mrouted.conf | grep -v ^#
name CAMERA 239.255.42.42/32
phyint vio0 disable

1) When I start the two tun0 and tun1 interfaces, the command says:

# ./mroutectl

Interface Table
Address         Interface       State Cost TTL    Uptime Flags
10.200.200.2    tun0               Up    1   1   0:00:00 QL
10.201.201.2    tun1               Up    1   1   0:00:00 QL

DVMRP Routing Table
Origin          Neighbor        Interface
10.201.201.0/30 Local           tun1
10.200.200.0/30 Local           tun0

The routes of the tun interfaces are:

# route -n show -inet | grep -v -w vio0 | grep -v -w lo0
Routing tables

Internet:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
10.200.200.1       10.200.200.2       UH         0        1     -     8 tun0
10.200.200.2       10.200.200.2       UHl        0        5     -     1 tun0
10.201.201.1       10.201.201.2       UH         0        4     -     8 tun1
10.201.201.2       10.201.201.2       UHl        0       11     -     1 tun1

2) When I start to send multicast traffic on tun0 to 239.255.42.42, mroutectl doesn't change, but a route is added to tun0:

# ./mroutectl

Interface Table
Address         Interface       State Cost TTL    Uptime Flags
10.200.200.2    tun0               Up    1   1   0:00:00 QL
10.201.201.2    tun1               Up    1   1   0:00:00 QL

DVMRP Routing Table
Origin          Neighbor        Interface
10.201.201.0/30 Local           tun1
10.200.200.0/30 Local           tun0
# route -n show -inet | grep -v -w vio0 | grep -v -w lo0
Routing tables

Internet:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
10.200.200.1       10.200.200.2       UH         0        1     -     8 tun0
10.200.200.2       10.200.200.2       UHl        0        5     -     1 tun0
10.201.201.1       10.201.201.2       UH         0        4     -     8 tun1
10.201.201.2       10.201.201.2       UHl        0       11     -     1 tun1
239.255.42.42      10.200.200.2       UHm        0      257     -     8 tun0

3) when I send a smcroutectl join tun1 239.255.42.42, I see:

# ./mroutectl

Interface Table
Address         Interface       State Cost TTL    Uptime Flags
10.200.200.2    tun0               Up    1   1   0:00:00 QL
10.201.201.2    tun1               Up    1   1   0:00:00 QL

DVMRP Routing Table
Origin          Neighbor        Interface
10.201.201.0/30 Local           tun1
10.200.200.0/30 Local           tun0

Multicast Forwarding Cache Table
Origin          Group           Inbound         Outbound
10.200.200.0/30 239.255.42.42   tun0            tun1

and a second route for 239.255.42.42:

# route -n show -inet | grep -v -w vio0 | grep -v -w wg0 | grep -v -w lo0
Routing tables

Internet:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
10.200.200.1       10.200.200.2       UH         0        1     -     8 tun0
10.200.200.2       10.200.200.2       UHl        0        5     -     1 tun0
10.201.201.1       10.201.201.2       UH         0        4     -     8 tun1
10.201.201.2       10.201.201.2       UHl        0       11     -     1 tun1
239.255.42.42      10.200.200.2       UHmP       0       12     -     8 tun0
239.255.42.42      10.201.201.2       UHmP       0        0     -     8 tun1

I can see the multicast traffic routed to tun1 with a tcp dump.

4) when I send a smcroutectl leave tun1 239.255.42.42, the traffic stops flowing through tun1

Thanks a lot! Regards

troglobit commented 3 years ago

Cool, great to hear you got it working! :)

FYI, I think netstat -g and netstat -g -s shows the multicast routing table in OpenBSD. You should not need to have any multicast routes in your regular unicast routing table.

lucdig commented 3 years ago

Important, if you use PF on OpenBSD. I also needed to add, in /etc/pf.conf pass in quick on tun all allow-opts to make igmp join's not to be filtered out