Hi Ruud,
On 7/22/09 8:47 AM, "Ruud Klaver" <r...@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 _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
