4

Good day all

My application makes primary use of Multicast packets on

ip = 224.8.0.1

I have tested over normal Wifi/Ethernet and hosted networks, which are all good.

Problem:

My OpenVZ server runs OpenVPN:UDP. My application should allow multicast packets to flow through the VPN and be recieved by any other client connected to the VPN, however it doesn't.

I did a tcpdump on the OpenVPN tun0 adapter, no multicast traffic is sent, however on the sender side, wireshark detects traffic being sent.

After research, I came across this post

https://openvpn.net/archive/openvpn-devel/2004-04/msg00032.html

I'd try switching to 'dev tap' (no bridging) to see if that helps.

I did see some old reports about multicast/igmp not working over tun devices, but have also read reports that it 'now works' ...

Also make sure you've disabled rp_filter on the tun device, as multicast address don't pass the 'rp_filter' check (/proc/sys/net/ipv4/conf/*/rp_filter)

I am not able to switch to tap, thus I tried to echo 1 > ../../rp_filter but it is write protected.

Based on another post, here are 3 possible solutions:

https://community.openvpn.net/openvpn/ticket/79

(1) Let the kernel do the routing. That means falling back to one OpenVPN daemon on each end of the tunnel, as in 1.x.

(2) Use a tun interface in OpenVPN 2.0 in multiclient mode. This will treat multicast like broadcast.

(3) Use multicast tunnels -- this will tunnel the multicast packets through OpenVPN encapuslated in an IP-in-IP container which should work fine.

Another [possible][3] solution is:

you'd need to sniff and intercept IGMP packets coming in, maintain multicast routing state, and replicate multicast packets according to a newly introduced multicast forwarding table.

Option (3) seems most appropriate, but I have no idea how to set this up.

Could someone assist me with this?

server.conf

port 1025
proto udp
dev tun

ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh2048.pem

server 10.0.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
route 10.0.0.2 255.255.255.252
push "redirect-gateway def1"

push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

client-to-client

keepalive 10 120
comp-lzo no

user nobody
group nogroup

persist-key
persist-tun

status openvpn-status.log
log-append  openvpn.log
verb 4

#possible bandwidth increase
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"
push "remote-gateway x.x.x.x"
push "dhcp-option DNS 8.8.8.8"
ccd-exclusive

#for checking active clients
management localhost 7505

iptables is good, I recently added

iptables -A INPUT -i tun0 -m pkttype --pkt-type multicast -j ACCEPT

iptables -A INPUT -i tun0 --protocol igmp -j ACCEPT

but no luck

CybeX
  • 273
  • 2
  • 6
  • 17
  • Why are you not able to switch to tap? `intercept IGMP` means to redirect it somehow (we need details what you wanna do), INPUT chain is to accept traffic to server, you want modify PREROUTING and POSTROUTING chains, how? It depends what do you wanna do with your IGMP traffic. You need broadcast multiaccess network, thus tun is useless. – Michal Sokolowski Jan 18 '16 at 12:35
  • @MichalSokolowski what makes tun "useless", isn't it possible to tunnel these multicast packets? I am looking at smcroute but I have little faith in it...or maybe my config is just wrong :p – CybeX Jan 18 '16 at 12:44
  • @MichalSokolowski reason for tun and not tap is Android only allows tun for the moment – CybeX Jan 18 '16 at 14:04
  • Okay, I get your problem now, I am not an expert with android operating system, but can you configure there l2tp tunnel? The goal would be to establish layer two connection (ISO/OSI model) on top of layer 3 VPN which should give you access to boradcast multiaccess network. – Michal Sokolowski Jan 19 '16 at 09:35

0 Answers0