[Freeswitch-users] Routing/NAT issues with head?

[sangdrax8]

If anyone else is having a similar issue, I have created jira ticket
#FS-6691

To clarify the issue, some RTP packets are initially sent out an
unexpected/incorrect interface when the session first begins.  It seems
that freeswitch will eventually send the packets the correct direction, if
the clients continue to send traffic from the correct IP.  In my test
setup, these rogue RTP packets going the wrong direction actually cause
incorrect entries in my firewall.  This leads to the clients not getting
their source translated any more, and exaggerates this condition.


On Thu, Jul 24, 2014 at 9:35 AM, sangdrax8 <sangdrax8 at gmail.com> wrote:

> I am trying to get the current git pull to work using the default
> configurations that are provided.  I am having issues that seem related to
> routing, or possibly NAT.  Let me try and explain my issue, and see if
> someone knows there is a setting I am missing or if this is actually some
> strange bug.
>
> Basic setup:
> I am using the default configuration provided, only changing the default
> password for clients.  My test machine has 2 interfaces, eth0 on the
> internet (no NAT), and eth1 on an internal RFC address.  With the default
> configuration, the "internal" profile is on the internet address from eth0
> on port 5060.  The "external" profile is on the same eth0 ip, on port 5080.
>
> Problem:
> So everything looks normal, and I can register two soft clients
> (Groundwire, one android one iPhone) to the internal profile.  When I place
> a call between 1000 and 1001, the SIP packets all work exactly as expected,
> but I get no audio.  Using these same to clients on an older build (still
> 1.5.x) in my production environment works just fine.  So I would think the
> clients settings are fairly standard.
>
> Looking at the server, I found that the freeswitch is sending the audio
> packets to the RFC address of my clients (192.168.x.x) and is deciding to
> send these packets out my eth1 interface.  Now I do route all RFC's out
> eth1, so this test server can be connected to from the inside.  It doesn't
> have an interface in the same subnet as the clients though, just a route
> for all RFC's internally.  Testing a theory, I removed the route to the
> 192.168.x.x range which the phones happen to be in (wifi network gets NAT
> to the internet when connecting to this machine as most clients probably
> do).  Once I do this, and with no changes to my freeswitch, the audio
> works.  With out this route on the base server, freeswitch sends the UDP
> packets out eth0, back to the correct Internet IP my clients connected from.
>
> I thought maybe this had something to do with nat.auto, or localnet.auto,
> but using the acl cli command, it would seem these things all check out
> correctly.  When I ask it if the 192.168 net is in the nat.auto it returns
> true, so it would see to know it SHOULD be natting for that network.  The
> only false I get is for the subnet that my eth0 is in.
>
> If, by chance, I had been testing with a range that my server didn't have
> a route to (if I didn't route all RFC's internally) I probably wouldn't
> have seen this.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140725/4073c616/attachment.html