I don't know the details about igmpproxy. Looking a little bit in the source-code it seems that it installs a route inside in the kernel for a certain multicast-stream. Thus, multicast-udp will pass your gateway as they don't hit the INPUT chain. However for the igmp-control traffic I have no idea, why igmpproxy receives these. Christoph On Fri 26 February 2010, ratheesh k wrote: > I am running igmp stream client to stream igmp packets on machine A > from internet .I can play files . > > note : Is igmpproxy running machine B has anything to do with this ? > > > > On Fri, Feb 26, 2010 at 12:11 PM, Christoph Paasch > > <christoph.paasch@xxxxxxxxx> wrote: > > On Fri 26 February 2010, ratheesh k wrote: > >> INPUT policy is DROP > >> FORWARD policy is DROP > >> OUTPUT policy is accept > >> > >> > >> INPUT chain > >> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > >> iptables -A INPUT -i eth0 -j ACCEPT > >> > >> > >> FORWARD > >> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > >> iptables -A INPUT -i eth0 -o eth1 -j ACCEPT > > > > I imagine that this is a typo and that you meant the FORWARD chain. > > > >> machine Gateway machine B > >> A -------------------->eth0 eth1 -------------> internet > >> > >> I have a machine A . which is connected to a linux gateway machine . > >> Ruleset and policy mentioned are for machine B . There is no iptables > >> rules in machine A . > >> > >> >>>>>>>>>What do you want to achieve ? > >> > >> As per the current rule , no igmp packet should come to GATEWAY > >> machine , since there is no firewall hole in input chain . > >> > >> >>>>>>>>>>what are you observing? > >> > >> But i can see , igmp packets flowing into machine B from internet . > > > > Where can you see these igmp packets? With wireshark/tcpdump? If it is > > one of those, than it is normal, because these capture the packets > > before the iptables filter. > > > > Seen your ruleset, the packets should not enter, if they are coming from > > the internet. > > > > Regards, > > Christoph > > > >> On Fri, Feb 26, 2010 at 4:46 AM, Christoph Paasch > >> > >> <christoph.paasch@xxxxxxxxx> wrote: > >> > Please, provide more information about your setup. > >> > > >> > What are the policies of your chains? What is your ruleset? > >> > What is your topology? > >> > What do you want to achieve, and what are you observing? > >> > > >> > Christoph > >> > > >> > On Thu 25 February 2010 wrote ratheesh k: > >> >> iptables -A INPUT -m state --state ESTABLISHED,RELATES -j ACCEPT . > >> >> > >> >> This is the only rule . No firewall hole for igmp packets . > >> >> > >> >> On Thu, Feb 25, 2010 at 12:08 PM, ratheesh k <ratheesh.ksz@xxxxxxxxx> > > > > wrote: > >> >> >>>>>>>>>>udp doesn't go into the established state. > >> >> > > >> >> > I am running "igmpproxy" on my gateway box . I didnot add any rule > >> >> > in INPUT chain to accept igmp packets . But i hve a rule to > >> >> > accept all ESTABLISHED state packets . It am able to stream igmp > >> >> > from my desktop . > >> >> > > >> >> > I really believe that " We dont need any rule in FORWARD chain " . > >> >> > Because packets are flowing from node to node and routed . So only > >> >> > INPUT and OUTPUT chains are involved . > >> >> > > >> >> > Thanks, > >> >> > Ratheesh > >> >> > > >> >> > > >> >> > > >> >> > On Thu, Feb 25, 2010 at 12:03 AM, Christoph Paasch > >> >> > > >> >> > <christoph.paasch@xxxxxxxxx> wrote: > >> >> >> As long as there isn't any return-traffic (as it is the case for > >> >> >> multicast- udp), udp doesn't go into the established state. > >> >> >> > >> >> >> Regards, > >> >> >> Christoph > >> >> >> > >> >> >> On Wed 24 February 2010 wrote ratheesh k: > >> >> >>> multicast packets are udp packets . But its flowing only from > >> >> >>> upstream to downstream . So packet state will be always "NEW" . > >> >> >>> ?? > >> >> >>> > >> >> >>> my question is : whether we can see multicast data packets in > >> >> >>> ESTABLISHED state ?? > >> >> >>> > >> >> >>> Thanks, > >> >> >>> Ratheesh > >> >> >>> -- > >> >> >>> To unsubscribe from this list: send the line "unsubscribe > >> >> >>> netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx > >> >> >>> More majordomo info at > >> >> >>> http://vger.kernel.org/majordomo-info.html > >> >> >> > >> >> >> -- > >> >> >> Christoph Paasch > >> >> >> > >> >> >> Alcatel-Lucent > >> >> >> IP Development > >> >> >> > >> >> >> www.rollerbulls.be > >> >> >> -- > >> >> >> -- > >> >> >> To unsubscribe from this list: send the line "unsubscribe > >> >> >> netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx > >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> >> > >> >> -- > >> >> To unsubscribe from this list: send the line "unsubscribe netfilter" > >> >> in the body of a message to majordomo@xxxxxxxxxxxxxxx > >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> > > >> > -- > >> > Christoph Paasch > >> > > >> > Alcatel-Lucent > >> > IP Development > >> > > >> > www.rollerbulls.be > >> > -- > >> > >> -- > >> To unsubscribe from this list: send the line "unsubscribe netfilter" in > >> the body of a message to majordomo@xxxxxxxxxxxxxxx > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > > Christoph Paasch > > > > Alcatel-Lucent > > IP Development > > > > www.rollerbulls.be > > -- > > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Christoph Paasch Alcatel-Lucent IP Development www.rollerbulls.be -- -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
