[OpenSIPS-Users] mediaproxy stops relaying packets

[Jeff Pyle]

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