media-relay not relaying when iptables running

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

media-relay not relaying when iptables running

JimDoesVoip
Hi All, We're running opensips 1.6.4 and mediaproxy 2.5.2, both on a single server running centos 6. When iptables is turned off media-relay works properly, calls connect and have audio, we see media flow from a IP client, to the media-relay back to IP client. We can't see any entries using the conntrack -L command at this time (maybe because iptables is off?) When we turn iptables on, we see entries in conntrack -L for a bunch of items including the sip signaling to each of the clients, but we do not see any entries for media when in a call (should we?). Our iptables config adds a few accept lines to the filter chain to allow any traffic on a few private interfaces and to allow sip traffic on a high port on any interface. These keep opensips working while iptables is running.
# iptables -t filter -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  203 23785 ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED 
    2   152 ACCEPT     icmp --  any    any     anywhere             anywhere            
    1   201 ACCEPT     all  --  lo     any     anywhere             anywhere            
    7  3629 ACCEPT     all  --  bond0  any     anywhere             anywhere            
    0     0 ACCEPT     all  --  eth0   any     anywhere             anywhere            
    0     0 ACCEPT     all  --  eth1   any     anywhere             anywhere            
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:ssh 
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:15060 
    9  1177 ACCEPT     udp  --  any    any     anywhere             anywhere            state NEW udp dpt:15060 
    0     0 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT 137 packets, 33701 bytes)
 pkts bytes target     prot opt in     out     source               destination         


# iptables -t raw -L -v   
Chain PREROUTING (policy ACCEPT 11495 packets, 2699K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 118 packets, 32010 bytes)
 pkts bytes target     prot opt in     out     source               destination         
# 
It seems like something isn't getting connected properly, but unfortunately I didn't find a similar problem. When iptables is running there are no errors from media-relay, but no audio is relayed. When iptables is off we see errors complaining about iptables not being loaded, but media is relayed / works in both directions. Thanks very much, Jim O
Reply | Threaded
Open this post in threaded view
|

Re: media-relay not relaying when iptables running

Saúl Ibarra Corretgé
Hi,

On Oct 20, 2011, at 8:33 AM, JimDoesVoip wrote:

> Hi All, We're running opensips 1.6.4 and mediaproxy 2.5.2, both on a single server running centos 6. When iptables is turned off media-relay works properly, calls connect and have audio, we see media flow from a IP client, to the media-relay back to IP client. We can't see any entries using the conntrack -L command at this time (maybe because iptables is off?) When we turn iptables on, we see entries in conntrack -L for a bunch of items including the sip signaling to each of the clients, but we do not see any entries for media when in a call (should we?). Our iptables config adds a few accept lines to the filter chain to allow any traffic on a few private interfaces and to allow sip traffic on a high port on any interface. These keep opensips working while iptables is running.
> # iptables -t filter -L -v
> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source               destination        
>   203 23785 ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
>     2   152 ACCEPT     icmp --  any    any     anywhere             anywhere            
>     1   201 ACCEPT     all  --  lo     any     anywhere             anywhere            
>     7  3629 ACCEPT     all  --  bond0  any     anywhere             anywhere            
>     0     0 ACCEPT     all  --  eth0   any     anywhere             anywhere            
>     0     0 ACCEPT     all  --  eth1   any     anywhere             anywhere            
>     0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:ssh
>     0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:15060
>     9  1177 ACCEPT     udp  --  any    any     anywhere             anywhere            state NEW udp dpt:15060
>     0     0 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited
>
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source               destination        
>     0     0 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited
>
> Chain OUTPUT (policy ACCEPT 137 packets, 33701 bytes)
>  pkts bytes target     prot opt in     out     source               destination        
>
>
> # iptables -t raw -L -v  
> Chain PREROUTING (policy ACCEPT 11495 packets, 2699K bytes)
>  pkts bytes target     prot opt in     out     source               destination        
>
> Chain OUTPUT (policy ACCEPT 118 packets, 32010 bytes)
>  pkts bytes target     prot opt in     out     source               destination        
> #
>
> It seems like something isn't getting connected properly, but unfortunately I didn't find a similar problem. When iptables is running there are no errors from media-relay, but no audio is relayed. When iptables is off we see errors complaining about iptables not being loaded, but media is relayed / works in both directions. Thanks very much, Jim O

What do you mean by "iptables on"? Having the modules loaded and forwarding enabled in /proc is enough. I'm not sure about what CentOS may do when you start the iptables service, we don't use that with Debian :-S

You should see entries in both the raw table and conntrack -L. You also mentioned that in some case you got an error, can you paste it?


Regards,

--
Saúl Ibarra Corretgé
AG Projects




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: media-relay not relaying when iptables running

JimDoesVoip
Hi Saúl,

  I have this little voice in the back of my head telling me to switch to debian.  I'm too stubborn to give up sometimes, but feeling like we are close a switch now; if we want fail2ban watching opensips and to coexisting with media-relay... but back on topic.

  We do have the modules loaded, and we do have the forwarding enabled in /proc, so it makes sense that things are working; Unfortnately as the thread says if we want to startup iptables (run /etc/init.d/iptables) to be able to run something like fail2ban against it, it seems it is interfering media-relay.  What is strange is that conntrack -L shows entries (for SIP signaling) when iptables service is running, but doesn't show anything when it is off.

Interestingly, if we setup a call with iptables running, we have no audio, but then if we stop iptables audio comes through for the call.  Could this mean media-relay is setting things up, but they are blocked by iptables?


  When we have a no audio call with iptables running; the media-relay /var/log/messages output just notes the ports that are being setup and closed.


Oct 20 10:49:42 bstnma-ospis1-b2 media-relay[19908]: mediaproxy.mediacontrol.StreamListenerProtocol starting on 40072
Oct 20 10:49:42 bstnma-ospis1-b2 media-relay[19908]: mediaproxy.mediacontrol.StreamListenerProtocol starting on 40073
Oct 20 10:49:42 bstnma-ospis1-b2 media-relay[19908]: mediaproxy.mediacontrol.StreamListenerProtocol starting on 40074
Oct 20 10:49:42 bstnma-ospis1-b2 media-relay[19908]: mediaproxy.mediacontrol.StreamListenerProtocol starting on 40075

Oct 20 10:50:31 bstnma-ospis1-b2 media-relay[19908]: (Port 40072 Closed)
Oct 20 10:50:31 bstnma-ospis1-b2 media-relay[19908]: (Port 40073 Closed)
Oct 20 10:50:31 bstnma-ospis1-b2 media-relay[19908]: (Port 40074 Closed)
Oct 20 10:50:31 bstnma-ospis1-b2 media-relay[19908]: (Port 40075 Closed)



 Here is the error-ish looking output from mediarelay of /var/log/messages for a call that has audio with the iptables process off (/etc/init.d/iptables stop):


Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]: Traceback (most recent call last):
Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]:   File "/usr/lib/python2.6/site-packages/twisted/internet/udp.py", line 126, in doRead
Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]:     self.protocol.datagramReceived(data, addr)
Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]:   File "/root/ISO/mediaproxy1/mediaproxy/mediacontrol.py", line 130, in datagramReceived
Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]:     self.cb_func(host, port, data)
Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]:   File "/root/ISO/mediaproxy1/mediaproxy/mediacontrol.py", line 246, in got_data
Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]:     self.substream.check_create_conntrack()
Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]:   File "/root/ISO/mediaproxy1/mediaproxy/mediacontrol.py", line 297, in check_create_conntrack
Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]:     self.forwarding_rule = _conntrack.ForwardingRule(self.caller.remote, self.caller.local, self.callee.remote, self.callee.local, self.stream.session.mark)
Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]: Error: iptables who? (do you need to insmod?)


Thanks,

Jim O


Reply | Threaded
Open this post in threaded view
|

Re: media-relay not relaying when iptables running

Jeff Pyle
In reply to this post by JimDoesVoip
Jim,

One difference between my iptables setup and yours on my relay is I allow the FORWARD to go, default policy ACCEPT.  Perhaps this is relevant.


- Jeff

On Oct 20, 2011, at 2:33 AM, JimDoesVoip wrote:

Hi All, We're running opensips 1.6.4 and mediaproxy 2.5.2, both on a single server running centos 6. When iptables is turned off media-relay works properly, calls connect and have audio, we see media flow from a IP client, to the media-relay back to IP client. We can't see any entries using the conntrack -L command at this time (maybe because iptables is off?) When we turn iptables on, we see entries in conntrack -L for a bunch of items including the sip signaling to each of the clients, but we do not see any entries for media when in a call (should we?). Our iptables config adds a few accept lines to the filter chain to allow any traffic on a few private interfaces and to allow sip traffic on a high port on any interface. These keep opensips working while iptables is running.
# iptables -t filter -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  203 23785 ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED 
    2   152 ACCEPT     icmp --  any    any     anywhere             anywhere            
    1   201 ACCEPT     all  --  lo     any     anywhere             anywhere            
    7  3629 ACCEPT     all  --  bond0  any     anywhere             anywhere            
    0     0 ACCEPT     all  --  eth0   any     anywhere             anywhere            
    0     0 ACCEPT     all  --  eth1   any     anywhere             anywhere            
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:ssh 
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:15060 
    9  1177 ACCEPT     udp  --  any    any     anywhere             anywhere            state NEW udp dpt:15060 
    0     0 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT 137 packets, 33701 bytes)
 pkts bytes target     prot opt in     out     source               destination         


# iptables -t raw -L -v   
Chain PREROUTING (policy ACCEPT 11495 packets, 2699K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 118 packets, 32010 bytes)
 pkts bytes target     prot opt in     out     source               destination         
# 
It seems like something isn't getting connected properly, but unfortunately I didn't find a similar problem. When iptables is running there are no errors from media-relay, but no audio is relayed. When iptables is off we see errors complaining about iptables not being loaded, but media is relayed / works in both directions. Thanks very much, Jim O

View this message in context: media-relay not relaying when iptables running
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
<ATT00001..txt>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: media-relay not relaying when iptables running

Saúl Ibarra Corretgé
In reply to this post by JimDoesVoip
Hi,

On Oct 20, 2011, at 4:54 PM, JimDoesVoip wrote:

> Hi Saúl,
>
>  I have this little voice in the back of my head telling me to switch to
> debian.  I'm too stubborn to give up sometimes, but feeling like we are
> close a switch now; if we want fail2ban watching opensips and to coexisting
> with media-relay... but back on topic.
>

Listen to it, you know she is right ;-)

>  We do have the modules loaded, and we do have the forwarding enabled in
> /proc, so it makes sense that things are working; Unfortnately as the thread
> says if we want to startup iptables (run /etc/init.d/iptables) to be able to
> run something like fail2ban against it, it seems it is interfering
> media-relay.  What is strange is that conntrack -L shows entries (for SIP
> signaling) when iptables service is running, but doesn't show anything when
> it is off.
>

Probably we'd find the answer by looking at what that init file does...

> Interestingly, if we setup a call with iptables running, we have no audio,
> but then if we stop iptables audio comes through for the call.  Could this
> mean media-relay is setting things up, but they are blocked by iptables?
>

Jeff just pointed out that your default policy for FORWARD is reject, can you change it to accept?

>
>  When we have a no audio call with iptables running; the media-relay
> /var/log/messages output just notes the ports that are being setup and
> closed.
>
>
> Oct 20 10:49:42 bstnma-ospis1-b2 media-relay[19908]:
> mediaproxy.mediacontrol.StreamListenerProtocol starting on 40072
> Oct 20 10:49:42 bstnma-ospis1-b2 media-relay[19908]:
> mediaproxy.mediacontrol.StreamListenerProtocol starting on 40073
> Oct 20 10:49:42 bstnma-ospis1-b2 media-relay[19908]:
> mediaproxy.mediacontrol.StreamListenerProtocol starting on 40074
> Oct 20 10:49:42 bstnma-ospis1-b2 media-relay[19908]:
> mediaproxy.mediacontrol.StreamListenerProtocol starting on 40075
>
> Oct 20 10:50:31 bstnma-ospis1-b2 media-relay[19908]: (Port 40072 Closed)
> Oct 20 10:50:31 bstnma-ospis1-b2 media-relay[19908]: (Port 40073 Closed)
> Oct 20 10:50:31 bstnma-ospis1-b2 media-relay[19908]: (Port 40074 Closed)
> Oct 20 10:50:31 bstnma-ospis1-b2 media-relay[19908]: (Port 40075 Closed)
>
>
>
> Here is the error-ish looking output from mediarelay of /var/log/messages
> for a call that has audio with the iptables process off
> (/etc/init.d/iptables stop):
>
>
> Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]: Traceback (most recent
> call last):
> Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]:   File
> "/usr/lib/python2.6/site-packages/twisted/internet/udp.py", line 126, in
> doRead
> Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]:    
> self.protocol.datagramReceived(data, addr)
> Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]:   File
> "/root/ISO/mediaproxy1/mediaproxy/mediacontrol.py", line 130, in
> datagramReceived
> Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]:     self.cb_func(host,
> port, data)
> Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]:   File
> "/root/ISO/mediaproxy1/mediaproxy/mediacontrol.py", line 246, in got_data
> Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]:    
> self.substream.check_create_conntrack()
> Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]:   File
> "/root/ISO/mediaproxy1/mediaproxy/mediacontrol.py", line 297, in
> check_create_conntrack
> Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]:    
> self.forwarding_rule = _conntrack.ForwardingRule(self.caller.remote,
> self.caller.local, self.callee.remote, self.callee.local,
> self.stream.session.mark)
> Oct 20 10:03:52 bstnma-ospis1-b2 media-relay[19908]: Error: iptables who?
> (do you need to insmod?)
>
>

This is probably caused because the nat table is missing because stopping iptables unloaded it. MediaProxy checks for this, but only at start time.


Regards,

--
Saúl Ibarra Corretgé
AG Projects




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: media-relay not relaying when iptables running

JimDoesVoip
In reply to this post by Jeff Pyle
Hi Jeff,
  Thanks.  I looked at this earlier as well.  I swapped the REJECT line out for a blanked ACCEPT with forwards and it didn't seem to have an effect.  I keep wondering if there is something in raw that needs to be put in place based upon the messages from iptables as it exists.  I took another look based on your note and I think I found something meaningful.

  iptables (at least on centos) appears to load different tables independently when you use the --list option.  So I started a call with only the raw table loaded.  no audio.  I then stopped iptables and had audio.  I then loaded filter and nat tables and each time still had audio.  Then as the call was going I loaded the raw table, and the call still had audio.  I stopped the call and started a new one: no audio.  Unloaded the raw table; audio.  

# iptables -t raw --list  
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        
# /etc/init.d/iptables stop
iptables: Flushing firewall rules:                         [  OK  ]
iptables: Setting chains to policy ACCEPT: raw             [  OK  ]
iptables: Unloading modules:                               [  OK  ]
#


So it feels likely that the raw part of my iptables config is blocking things.  Perhaps, even though it says it is defaulting to ACCEPT, it is blocking packets from getting to conntrack rules setup by media-relay?

Thanks,

Jim



Jeff Pyle wrote
Jim,

One difference between my iptables setup and yours on my relay is I allow the FORWARD to go, default policy ACCEPT.  Perhaps this is relevant.


- Jeff
Reply | Threaded
Open this post in threaded view
|

Re: media-relay not relaying when iptables running

Jeff Pyle
Hi Jim,

Huh.  That's scary yet interesting.  I dumped CentOS a in favor of Debian for my Opensips/Mediaproxy adventures a while back because in many ways, things "just work better".  I can't say I had these issues in CentOS, however.  Both CentOS and Mediaproxy were at significantly older versions.  Perhaps that's related.

On my Debian (lenny) relays, I restore the iptables rules from a file as a function of the interface (pre-up).  Seems to work fairly well.  Here's most of the iptables-save output from the relay.  This matches the iptables.rules file I restore with the exception of the snipped parts and the counters:

# Generated by iptables-save v1.4.2 on Thu Oct 20 12:56:50 2011
*raw
:PREROUTING ACCEPT [24582234842:4809548355202]
:OUTPUT ACCEPT [154571950:31256363599]
COMMIT
# Completed on Thu Oct 20 12:56:50 2011
# Generated by iptables-save v1.4.2 on Thu Oct 20 12:56:50 2011
*nat
:PREROUTING ACCEPT [12968687:1476480376]
:POSTROUTING ACCEPT [1936336:370965482]
:OUTPUT ACCEPT [1936336:370965482]
COMMIT
# Completed on Thu Oct 20 12:56:50 2011
# Generated by iptables-save v1.4.2 on Thu Oct 20 12:56:50 2011
*mangle
:PREROUTING ACCEPT [24582237485:4809548896216]
:INPUT ACCEPT [203005278:39797729208]
:FORWARD ACCEPT [24379232207:4769751167008]
:OUTPUT ACCEPT [154572287:31256447734]
:POSTROUTING ACCEPT [24531204592:4800422567952]
-A POSTROUTING -p udp -m udp --sport 16384:32768 -j DSCP --set-dscp 0x2e
COMMIT
# Completed on Thu Oct 20 12:56:50 2011
# Generated by iptables-save v1.4.2 on Thu Oct 20 12:56:50 2011
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [24379232256:4769751176468]
:OUTPUT ACCEPT [151972385:30671400944]
[snip]
-A INPUT -p udp -m udp --dport 16384:32768 -j ACCEPT
[snip]
-A INPUT -j DROP
COMMIT
# Completed on Thu Oct 20 12:56:50 2011

As far I can tell that's rather straight forward.  As you might suspect I declare 16384:32768 in the relay's config.  I suspect there's nothing in there surprising to you.


- Jeff


On Oct 20, 2011, at 11:44 AM, JimDoesVoip wrote:

> Hi Jeff,
>  Thanks.  I looked at this earlier as well.  I swapped the REJECT line out
> for a blanked ACCEPT with forwards and it didn't seem to have an effect.  I
> keep wondering if there is something in raw that needs to be put in place
> based upon the messages from iptables as it exists.  I took another look
> based on your note and I think I found something meaningful.
>
>  iptables (at least on centos) appears to load different tables
> independently when you use the --list option.  So I started a call with only
> the raw table loaded.  no audio.  I then stopped iptables and had audio.  I
> then loaded filter and nat tables and each time still had audio.  Then as
> the call was going I loaded the raw table, and the call still had audio.  I
> stopped the call and started a new one: no audio.  Unloaded the raw table;
> audio.  
>
> # iptables -t raw --list  
> Chain PREROUTING (policy ACCEPT)
> target     prot opt source               destination        
>
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination        
> # /etc/init.d/iptables stop
> iptables: Flushing firewall rules:                         [  OK  ]
> iptables: Setting chains to policy ACCEPT: raw             [  OK  ]
> iptables: Unloading modules:                               [  OK  ]
> #
>
>
> So it feels likely that the raw part of my iptables config is blocking
> things.  Perhaps, even though it says it is defaulting to ACCEPT, it is
> blocking packets from getting to conntrack rules setup by media-relay?
>
> Thanks,
>
> Jim
>
>
>
>
> Jeff Pyle wrote:
>>
>> Jim,
>>
>> One difference between my iptables setup and yours on my relay is I allow
>> the FORWARD to go, default policy ACCEPT.  Perhaps this is relevant.
>>
>>
>> - Jeff
>>
>>
>>
>
>
> --
> View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/media-relay-not-relaying-when-iptables-running-tp6911797p6913422.html
> Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: media-relay not relaying when iptables running

Saúl Ibarra Corretgé
In reply to this post by JimDoesVoip
Hi,

On Oct 20, 2011, at 5:44 PM, JimDoesVoip wrote:

> Hi Jeff,
>  Thanks.  I looked at this earlier as well.  I swapped the REJECT line out
> for a blanked ACCEPT with forwards and it didn't seem to have an effect.  I
> keep wondering if there is something in raw that needs to be put in place
> based upon the messages from iptables as it exists.  I took another look
> based on your note and I think I found something meaningful.
>
>  iptables (at least on centos) appears to load different tables
> independently when you use the --list option.  So I started a call with only
> the raw table loaded.  no audio.  I then stopped iptables and had audio.  I
> then loaded filter and nat tables and each time still had audio.  Then as
> the call was going I loaded the raw table, and the call still had audio.  I
> stopped the call and started a new one: no audio.  Unloaded the raw table;
> audio.  
>
> # iptables -t raw --list  
> Chain PREROUTING (policy ACCEPT)
> target     prot opt source               destination        
>
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination        
> # /etc/init.d/iptables stop
> iptables: Flushing firewall rules:                         [  OK  ]
> iptables: Setting chains to policy ACCEPT: raw             [  OK  ]
> iptables: Unloading modules:                               [  OK  ]
> #
>
>
> So it feels likely that the raw part of my iptables config is blocking
> things.  Perhaps, even though it says it is defaulting to ACCEPT, it is
> blocking packets from getting to conntrack rules setup by media-relay?
>

MediaProxy will use the raw table briefly to intercept the traffic in PREROUTING. Once the conntrack rule is up those rules in the raw table will go away.

Not sure what's going on there, it never happened to me before, alas I can't be of much help :-S


Regards,

--
Saúl Ibarra Corretgé
AG Projects




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: media-relay not relaying when iptables running

mmotani
In reply to this post by JimDoesVoip
Hi Folks,

I apologize in advance for resurrecting an old thread, but I have some new insight on the problem that Jim faced a few months ago with trying to run media-relay on CentOS 6. I have discovered that turning off SELinux allows media-proxy to relay media correctly without having to turn off the iptables service. I also do not get any of the syslog error messages that I normally get with SELinux and iptables running. Clearly, SELinux is preventing a system call to sockets because of insufficient authority for the media-relay process.

The perplexing thing, however, is that this restriction does not show up in the audit.log as most blocks by SELinux do. An analysis of audit.log using "sealert -a" does not show any references to media-relay, media-dispatcher, twisted or python.

If anybody has any insight on which rules in SELinux might be causing this issue, or how to diagnose this problem without any feedback in the audit.log, it would be much appreciated.

Muiz Motani

JimDoesVoip wrote
Hi All,
  We're running opensips 1.6.4 and mediaproxy 2.5.2, both on a single server running centos 6.  When iptables is turned off media-relay works properly, calls connect and have audio, we see media flow from a IP client, to the media-relay back to IP client.  We can't see any entries using the conntrack -L command at this time (maybe because iptables is off?)

  When we turn iptables on, we see entries in conntrack -L for a bunch of items including the sip signaling to each of the clients, but we do not see any entries for media when in a call (should we?).

  Our iptables config adds a few accept lines to the filter chain to allow any traffic on a few private interfaces and to allow sip traffic on a high port on any interface.  These keep opensips working while iptables is running.

<pre>
# iptables -t filter -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination        
  203 23785 ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
    2   152 ACCEPT     icmp --  any    any     anywhere             anywhere            
    1   201 ACCEPT     all  --  lo     any     anywhere             anywhere            
    7  3629 ACCEPT     all  --  bond0  any     anywhere             anywhere            
    0     0 ACCEPT     all  --  eth0   any     anywhere             anywhere            
    0     0 ACCEPT     all  --  eth1   any     anywhere             anywhere            
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:ssh
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:15060
    9  1177 ACCEPT     udp  --  any    any     anywhere             anywhere            state NEW udp dpt:15060
    0     0 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination        
    0     0 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 137 packets, 33701 bytes)
 pkts bytes target     prot opt in     out     source               destination        


# iptables -t raw -L -v  
Chain PREROUTING (policy ACCEPT 11495 packets, 2699K bytes)
 pkts bytes target     prot opt in     out     source               destination        

Chain OUTPUT (policy ACCEPT 118 packets, 32010 bytes)
 pkts bytes target     prot opt in     out     source               destination        
#
</pre>

It seems like something isn't getting connected properly, but unfortunately I didn't find a similar problem.  

When iptables is running there are no errors from media-relay, but no audio is relayed.  When iptables is off we see errors complaining about iptables not being loaded, but media is relayed / works in both directions.

Thanks very much,

Jim O