[OpenSIPS-Users] mediaproxy stops relaying packets

[Ruud Klaver]

Hi Jeff,

On 24 Jul 2009, at 04:36, Jeff Pyle wrote:

> Hi Ruud,
>
>
> On 7/22/09 8:47 AM, "Ruud Klaver" <ruud at ag-projects.com> wrote:
>
>> First of all, are you sure there is a correlation between the gateway
>> being used and mediaproxy working or not? Are all hosts on public  
>> IPs?
>
> After some testing tonight I discovered tonight there does appear to  
> be a
> correlation with the IPs.  Only one gateway succeeds, and it happens  
> to be
> on the same IP subnet as the mediaproxy relay itself.  The rest fail  
> as in
> the captures you've seen.  I don't know why.  I ruled out iptables by
> completely disabling my normal firewall rules.  And those are on the  
> INPUT
> table only; FORWARD is completely open.
>
>> Now for some reason the connection tracking rule doesn't seem to  
>> work,
>> but from what you gave me I cannot tell you why not, but this is the
>> direction you have to search in. A few questions you could look into:
>
>> - Are the connection tracking rules working for some calls but not  
>> for
>> others?
>
> That does seem to be the case, with the caveat listed above.
>
>> - Are all the IPs involved public, i.e. are they using the same
>> interface?
>
> All public, but the relay box itself has two different interfaces in  
> use
> (eth0 and eth1) with two different IPs on two different IPs  
> networks.  eth0
> is for all machine activity except voice, and eth1 is for voice.   
> The relay
> is bound to the eth1 IP.  I use route tables to send traffic out the  
> right
> interface based on the source IP.  All of my servers with any VoIP  
> on them
> at all are configured like this.  Other than Wireshark reporting bad  
> UDP
> checksums that aren't really bad, it works quite well.
>
> Except with Mediaproxy.  For whatever reason the relay seems to defy  
> this.
> It all goes to the system default gateway (and therefore out eth0)
> regardless of the table definitions and source IP.  In a sense it load
> balances by using one interface for inbound and the other for  
> outbound...
> My upstream layer-3 switch doesn't care where it comes from.  So,  
> unless
> this is causing some unseen problem, it's semi-intriguing but  
> irrelevant.
>
>> - Is the connection tracking rule actually installed, you can check  
>> by
>> using doing "conntrack -L" and grepping the list
>
> Yes.  There is a single rule that looks like this:
>
> # conntrack -L | grep [PSTN GW IP]
> udp      17 179 src=[CPE IP] dst=[Relay IP] sport=16968 dport=16392
> packets=366 bytes=73200 src=[PSTN GW IP] dst=[Relay IP] sport=10542
> dport=16394 packets=368 bytes=73600 [ASSURED] mark=0 secmark=0 use=1
>
> The packets and bytes counters do increment over time.  Tshark  
> showed the
> same behavior as in the captures I sent you.
>
>> - Is ip packet forwarding enabled in the proc filesystem?
>
> # cat /proc/sys/net/ipv4/ip_forward
> 1
>
>> - Is anything else on the system blocking forwarding of packets  
>> (maybe
>> in the FORWARD table)
>
> Iptables FORWARD is empty with policy ACCEPT.
>
>
>> In fact, what was that you mentioned about iptables?
>
> I have some INPUT rules, including this one:
> -A INPUT -i eth1 -m udp -p udp --dport 16384:32768 -j ACCEPT
>
> This came out of old Asterisk habits with its rtp.conf  I hadn't  
> thought
> through it enough to realize this relay was using FORWARD, not  
> INPUT.  Never
> mind.
>
> I've still got nothin'.  Any thoughts?  Perhaps the dual interfaces  
> somehow?
>
>
> - Jeff

Well, that INPUT rule should match against the initial few packets  
that go through user space, so if your default INPUT policy is REJECT  
you should add that rule, otherwise the relay never sees any packets...

I'm sure this is somehow related to the rather peculiar setup you  
have, using more than one public interface. That being said, I don't  
think it's impossible to use mediaproxy in this situation, but I  
assume the problem and solution can be found in your Linux system setup.

Let's first see if I understood your setup correctly:
- eth0 is used for anything but RTP relaying and the system default  
route is on the subnet attached to this interface.
- eth1 is used for RTP relaying and the media-relay is configured to  
use this IP. Is it indeed configured to do that?
- The Relay IP you've mentioned thus far is the IP of eth1. In fact,  
the IP of eth0 is not seen anywhere. Is that correct?
- The only PSTN gateway to which calls are successful are on the  
subnet that is attached to eth1.
- Although the default gateway is behind eth0, you have set up routing  
by using "route tables that set the next-hop of the packet based on  
the source
address". What does that mean exactly? Don't you mean destination IP?

I'm starting to suspect this may have something to do with a proc  
filesystem option called "rp_filter", but I don't know exactly what  
yet. Please confirm what I said above and give me some more details on  
your routing setup.

Ruud Klaver
AG Projects