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

[sangdrax8]

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/20140724/98363119/attachment.html