LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (http://www.linuxquestions.org/questions/linux-security-4/)
-   -   Iptables breaks mediastreaming from server (http://www.linuxquestions.org/questions/linux-security-4/iptables-breaks-mediastreaming-from-server-4175455225/)

LBM 03-23-2013 05:20 AM

Iptables breaks mediastreaming from server
 
I have a small server, from which I stream video files, from a samba share.

I have enabled iptables, and setup basic rules, but for some reason, when these rules are active, the streaming stops suddently. Sometimes already after 3 minutes, sometimes after 20 minutes, so there is no clear pattern.

I have tried to debug with tcpdump, but there is nothing to se here.

Any ideas to, what is causing this?

The iptables rule looks like this.
Code:

Chain INPUT (policy DROP 67 packets, 8666 bytes)
num  pkts bytes target    prot opt in    out    source              destination       
1        6  360 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:22 state NEW
2      22  2088 ACCEPT    udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:137 state NEW
3        1  236 ACCEPT    udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:138 state NEW
4        0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:139 state NEW
5        0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:445 state NEW
6      141  9533 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED


unSpawn 03-23-2013 06:03 AM

The best way to "debug" firewall rule sets is to use "-j LOG" rules before "-j DROP" decisions to see what actually gets dropped. Additionally attaching output of 'iptables-save' provides a more accurate view of what rules are actually in use.

LBM 03-25-2013 03:06 AM

Hi, thanks for replying. I am aware of the iptables-save output, but for me this output is not more accurate, actually the opposite. :)

But, I found the error, as show above, RELATED,ESTABLISHED was only specified for TCP, which was clearly a mistake. When allowing all protocols (byt not directly specifying TCP), it worked.

Addding the correct rule, after deleting the "corrupt" one.
Code:

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

LBM 03-25-2013 03:09 AM

Hi, thanks for replying. I am aware of the iptables-save output, but for me this output is not more accurate, actually the opposite. :)

But, I found the error, as show above, RELATED,ESTABLISHED was only specified for TCP, which was clearly a mistake. When allowing all protocols (byt not directly specifying TCP), it worked.

Addding the correct rule, after deleting the "corrupt" one.
Code:

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Noway2 03-25-2013 12:19 PM

That is an interesting twist, seeing as UDP does not have 'states' like TCP. This link suggests that IPTables may be remembering the IP:Port used as part of the connection tracking. It alludes to analysis of packets and replies, but there is nothing in UDP that says a reply is imminent.

LBM 03-26-2013 06:19 AM

Hi,

Thank you. Good "article"! :)

---------- Post added 26-03-13 at 12:19 ----------

Hi,

Thank you. Good "article"! :)


All times are GMT -5. The time now is 02:28 AM.