>>> >> >> >> 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.
You are absolutely right .
There is a packet processor running on the machine ,which offloads
the multicast stream . I was not aware of that . So you can add delete
iptables rules ,which unaffects packet processor stream .
I think , below rules are enough for igmp v2 to work .Could you please
verify this ? eth0 is lan interface and eth1 is wan interface . I
don't know whether we need rule no 3 ( R3 ) .
R1 . iptables -A INPUT -i eth1 -d 224.0.0.1 -j ACCEPT
R2 . iptables -A INPUT -i eth1 -d 224.0.0.2 -j ACCEPT
R3. iptables -A INPUT -i eth1 -p udp -d
$muticast-destination-address -j ACCEPT
R4. iptables -A -i eth1 -o eth0 -p udp -d
$muticast-destination-address -j ACCEPT
I have read tutorials which tells to add route for 224.0.0.0/4 . But
i have no route like this and still works . Is there any impact on
this .
Note :I am using igmpproxy .
Thanks,
Ratheesh
On Fri, Feb 26, 2010 at 2:52 PM, ratheesh k <ratheesh.ksz@xxxxxxxxx> wrote:
>>>>>>>>>>>>>Looking a little bit in the source-code it seems that it installs a route
>
> True . it installs multicast route { /prox/net/ip_mr_cache }.
> But route comes into play only at POSTROUTING hook . { after reaching
> box } .Since i dont have any rule in INPUT to accept those ,it should
> be rejected .
>
> You confirmed that IGMP wont go to ESTABLISHED state . I think , i
> have to debug more .
>
>
>
> On Fri, Feb 26, 2010 at 12:50 PM, Christoph Paasch
> <christoph.paasch@xxxxxxxxx> wrote:
>> 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
