<div dir="ltr">no. the multicast packets were generated by a remote server that has a TTL of 3.<br><br>There was a blog which talks about multicast on tap. I made those changes that he suggested, but it was in vain.<br><br><a href="http://blog.michael.kuron-germany.de/2015/07/arp-and-multicast-packets-lost-with-openvpn-in-tap-mode/">http://blog.michael.kuron-germany.de/2015/07/arp-and-multicast-packets-lost-with-openvpn-in-tap-mode/</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 14, 2016 at 1:32 AM, Guus Sliepen <span dir="ltr"><<a href="mailto:guus@tinc-vpn.org" target="_blank">guus@tinc-vpn.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, May 14, 2016 at 01:27:10AM +0800, Terry T wrote:<br>
<br>
> yes, ip_forward was turned on.<br>
><br>
> iptables is defaulted to ACCEPT policy on all the 3 chains.<br>
<br>
</span>Hm. What is generating the multicast traffic? Could it be that the TTL<br>
on the pacets is set to 1, so it will not be forwarded?<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Met vriendelijke groet / with kind regards,<br>
     Guus Sliepen <<a href="mailto:guus@tinc-vpn.org">guus@tinc-vpn.org</a>><br>
</div></div><br>_______________________________________________<br>
tinc mailing list<br>
<a href="mailto:tinc@tinc-vpn.org">tinc@tinc-vpn.org</a><br>
<a href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" rel="noreferrer" target="_blank">https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc</a><br>
<br></blockquote></div><br></div>