How do I forward multicast traffic between 2 different LANs using iptables?
Goal:
Need lmc or “LAN Messenger” to work on 2 lans separated by a Linux gateway using iptables.
Information:
- Must be this program “LAN Messenger”.
- Lmc uses multicast address 239.255.100.100:50000 to see users, then creates a tcp connection for chat.
- lan1 = olan1 = 192.168.2.0/24: gateway is a smart switch “Linksys Etherfast router” with filter multicast disabled.
- lan2 = slan1 = 10.10.10.0/24: gateway is the linux box
- gateway pc = Ubuntu 14 server. iptables to forward some traffic between lans.
iptable rules:
filter table:
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A FORWARD -i slan1 -o olan1 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m iprange --src-range 192.168.2.100-192.168.2.254 -j ACCEPT
-A FORWARD -i olan1 -o slan1 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i olan1 -o slan1 -p tcp -m tcp --dport 9696 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i olan1 -o slan1 -p tcp -m tcp --dport 50000 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i olan1 -o slan1 -p udp -m udp --dport 50000 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -s 224.0.0.0/4 -d 224.0.0.0/4 -j ACCEPT
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -p igmp -j ACCEPT
-A FORWARD -i olan1 -o slan1 -j DROP
nat table:
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -j MASQUERAD
Rules that I thought should forward multicast traffic:
-A FORWARD -i olan1 -o slan1 -p tcp -m tcp --dport 50000 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i olan1 -o slan1 -p udp -m udp --dport 50000 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -s 224.0.0.0/4 -d 224.0.0.0/4 -j ACCEPT
-A FORWARD -p igmp -j ACCEPT
Monitored the traffic of the gateway using tcpdump, I never saw multicast traffic go through as I changed iptable rules.
Will iptables forward multicast traffic?
Do I need to use a multicast routing daemon or proxy like pimd or smcroute?
Okay it looks like iptables alone is NOT the way to go.
I will try smcroute and/or pimd from the ubuntu repositories. So far I have not been able to make either one work.
Using smcroute:
iptables
-A INPUT -i lo -j ACCEPT
-A FORWARD -i slan1 -o olan1 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p igmp -j ACCEPT
-A FORWARD -i olan1 -o slan1 -p tcp -m tcp --dport 50000 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i olan1 -o slan1 -p udp -m udp --dport 50000 -m conntrack --ctstate NEW -j ACCEPT
-A PREROUTING -d 239.255.100.100/32 -j TTL --ttl-set 64
smcroute 2.3.1 from troglobit.
Extracted to /opt
./configure used default options.
configuration file at:
/usr/local/etc/smcroute.conf
#phyint olan1 enable ttl-threshold 1
phyint olan1 enable ttl-threshold 5
phyint slan1 enable ttl-threshold 5
mgroup from olan1 group 239.255.100.100
mgroup from slan1 group 239.255.100.100
mroute from olan1 group 239.255.100.100 to slan1
mroute from slan1 group 239.255.100.100 to olan
- ttl-threshold — is that minimum threshold?
- if the TTL on my packet is 1 does that mean the phyint will… ignore it. Changed to 5 just in case.
sudo smcrouted
sudo smcroutectl show groups
GROUP (S,G) INBOUND
(*, 239.255.100.100) slan1
(*, 239.255.100.100) olan1
sudo smcroutectl show routs
ROUTE (S,G) INBOUND PACKETS BYTES OUTBOUND
(*, 239.255.100.100) slan1 0 0 olan1
(*, 239.255.100.100) olan1 0 0 slan1
(10.10.10.154, 239.255.100.100) slan1 2 344 olan1
(192.168.2.53, 239.255.255.250) olan1 4 776
(10.10.10.101, 239.255.100.100) slan1 1 32 olan1
(192.168.2.101, 239.255.100.100) olan1 1 32 slan1
(10.10.10.1, 239.255.100.100) slan1 2 64 olan1
Not quite everybody…
On a WinXP multi-homed pc had to change a route:
route add 224.0.0.0 mask 240.0.0.0 10.10.10.153
need to use the interface number in place of the nic ip address…
- The metric goes to 1. Is this a TTL issue…
sudo smcroutectl show routs
ROUTE (S,G) INBOUND PACKETS BYTES OUTBOUND
(*, 239.255.100.100) slan1 0 0 olan1
(*, 239.255.100.100) olan1 0 0 slan1
(192.168.2.53, 239.255.255.250) olan1 4 776
(10.10.10.153, 239.255.100.100) slan1 1 32 olan1
LAN Messenger 1.2.32 network preferences
- Connection Timeout (seconds) — max out value
- Maximum number of retries — max out value
Make smcroute a daemon with Upstart on Ubuntu 14
/etc/init/smcroute.conf
# Upstart for custom compiled smcroute
## jc 2017 08 24
description "SMCRoute, a static multicast router"
author "jc"
# Stanzas
# Stanzas control when and how a process is started and stopped
# See a list of stanzas here: http://upstart.ubuntu.com/wiki/Stanzas#respawn
# When to start the service
# start on runlevel [2345]
start on (local-filesystems and net-device-up IFACE!=lo) or runlevel [2345]
# When to stop the service
#stop on runlevel [016]
stop on runlevel [!2345]
# Automatically restart process if crashed
expect fork
respawn
exec /usr/local/sbin/smcrouted -N -f /usr/local/etc/smcroute.conf -d 10 -l notice
Everything seems to work. Will let things run for a while with random reboots and occasional network outages, normal stuff.
TODO
Make smcroute a daemonMake route additions persistent- Verify iptables rule… is required
Make Win7 pc see subnet
I just tested smcroute with two network namespaces and two veth pairs. Setup:
ns1 <-- main namespace --> ns2
10.0.0.1 -- 10.0.0.254 10.0.1.254 -- 10.0.1.1
veth0b veth0a veth1a veth1b
The Debian smcroute package is version 2.0.0, and doesn’t seem to support virtual eth, so I installed version 2.3.1 from the smcroute homepage. The multicast route howto of smcroute is also very helpful.
I used the ssmping package to test multicasts. I ran ssmpingd in ns2, while pinging with ssmping -4 -I veth0b 10.0.1.1 from ns1. These are source-specific multicasts (SSM) using group 232.43.211.234, you can also test any-source multicasts (ASM) with asmping. I don’t know what LAN messenger uses.
I enabled forwarding in the main namespace to allow the unicast ping requests to get through, then did
smcroutectl add veth1a 10.0.1.1 232.43.211.234 veth0a
and everything worked fine. I would expect it also to work, adjusted to your setup, though you also may have to smcroutectl join to tell your switches they should forward multicasts properly. Multiple tcpdump terminal windows on all relevant interfaces greatly help with debugging.
I found the following pieces of information interesting:
To be able to setup multicast routes a program must connect to the
multicast routing socket in the kernel, when that socket is closed, which
is done automatically when a UNIX program ends, the kernel cleans up all
routes.
This means if you intend to use the multicast routing feature of the kernel, you must use a demon, not a commandline tool.
For static vs. dynamic routing, it says:
The intended purpose of smcroute is to aid in situations where dynamic
multicast routing does not work properly. However, a dynamic multicast
routing protocol is in nearly all cases the preferred solution. The reason
for this is their ability to translate Layer-3 signalling to Layer-2 and
vice versa (IGMP or MLD).
Finally, pay close attention to the TTL that is produced by your LAN messenger, see multicast FAQ at the end.