Re: VoIP conntrack issue

[Eliezer Croitoru <eliezer@ngtech.co.il>]

Hi Jörn,

You must first understand that you description is kind of vague on what 
the actual network setup is and you are just referring to specific 
things in the whole picture which what leads every reader to another 
conclusion.

I will try to write you the question that I still dont know the answer for:
what is the network path of the packets?(routing)
Where is this NAT happening?
I will give you an example that can clear up what We need to try to help 
you stay focused:
http://wiki.squid-cache.org/ConfigExamples/UbuntuTproxy4Wccp2#Toplogy

The above diagram shows and describes path and network diagram in a way 
that seems to me good.

192.168.1.38 sends packet to?
what external IP this router use? 114.XX.234.123 ?
if the IP of the asterisk server is:  122.XX.115.203 then what nat? to 
what direction? on what machine?
If it's a xen host that hosts the asterisk server I would say it's one 
of the bad choices ever(from my experience) to host VOIP server.
The whole question you are asking looks very weird from the conntrack 
output.

 From netfilter\technial point of view fire-walling is not NAT in any 
way while they both use some common modules.
(I dont know how much you know so I am now on the "syn-ack" part of the 
question from you to make sure we get the connection right and on the 
same src,dst logic)

If you do host any SIP service behind a firewall and\or nat you should 
be explicit on what is allowed to the direction of the SIP server.

I still dont understand how you managed to capture all this conntrack 
(topology+machines) data on the same machine.

If you do have problem with this specific part:
 > # The connection is assured, because Asterisk is basically listening
 > to everything on that port and changes the port it send the data back
 > # But my VoIP Provider is not that intelligent. :-((( See the following
 > [NEW] 192.168.1.38:44608 -> 62.52.147.185:35642  | 62.52.147.185:35642
 > ->114.XX.234.123:1030 [UNREPLIED]
 > [NEW] 62.52.147.185:35642 -> 114.XX.234.123:44608 |
 > 114.XX.234.123:44608 -> 62.52.147.185:35642 [UNREPLIED]
 > [NEW] 62.52.147.185:44609 -> 114.XX.234.123:44609 |
 > 114.XX.234.123:44609 -> 62.52.147.185:35643 [UNREPLIED]
 > [NEW] 192.168.1.38:57890 -> 62.52.147.185:35643 | 62.52.147.185:35643
 > -> 114.XX.234.123:57890 [UNREPLIED]

You should configure the RTP and SIP settings right.
how exactly the VOIP phone "192.168.1.38" contacts the PSTN provider 
"62.52.147.185" and why?(make it clear so I and others can understand 
the situation)
If you do have Asterisk server then this server should contact the 
SIP\PSTN provider and not the SIP phone.

The stun should be and should only be related to the external 
connections from the phone to a server in the internet.
Any other stuff should be static as possible to assure that the service 
will WORK.

You have mentioned:
/sbin/iptables -t nat -A POSTROUTING -j MASQUERADE -s 192.168.0.0/16
before which is not any mechanism of symmetric nat but more of 
snat(source nat).

NAT can never assure you symmetric port to port mapping and especially 
when you are natting more then 1000 hosts.
There is a great possibility that in such a wide NAT size you will have 
problems.
two clients can use somehow the same port in the same time.

My recommendation is that IF you can use even simple routing 
tunnel(IPIP\GRE) to avoid nat just use it.
it's simple to setup and supported on any linux distribution I know of.

(all the above is based on that I didnt understood the network 
infrastructure and is a speculation only until I will know more)

You can always contact me on my personal email to send me data you dont 
want to publish on the public lists.


Best Regards,
Eliezer

On 11/13/2012 1:42 PM, Jörn Krebs wrote:
> Hi Eliezer,
>
> I think your comment is a bit offensive, yes I understand how NAT
> works, and yes I know what STUN does,
> but in this case it is the NAT firewall who does some unneeded Port mapping!
>
> Setup:
> External IP: 114.XX.234.123
> Local Network : 192.168.1.0/24 -> Internal VoIP Phone: 192.168.1.38
> STUN Server: 216.93.246.14
> Asterisk Server: 122.XX.115.203
> VoIP-PSTN Provider: 62.52.147.185
>
> And what I do is:
> Call a number on my Asterisk Server, who then reroutes the call / the
> RTP stream directly to my VoIP Phone.
> (I tried directmedia and directrtpsetup, both do not work, because
> netfilter/conntrack does a port mapping.)
>
> I though you might be able to read this out of my first email, but to
> be honest, it was very hard to read,
> that's why I shortened the conntrack -E log and made it a bit more
> readable, and attach it here:
> ---------------------------------------------------------------------------------------------------------------------------------------
> # Here is the STUN-Part
> [NEW] 192.168.1.38:44608 -> 216.93.246.14:3478 | 216.93.246.14:3478 ->
> 114.XX.234.123:44608
> [NEW] 192.168.1.38:57890 -> 216.93.246.14:3478 | 216.93.246.14:3478 ->
> 114.XX.234.123:57890
> [UPDATE] 192.168.1.38:44608 -> 216.93.246.14:3478 | 216.93.246.14:3478
> -> 114.XX.234.123:44608 [ASSURED]
> [UPDATE] 192.168.1.38:57890 -> 216.93.246.14:3478 | 216.93.246.14:3478
> -> 114.XX.234.123:57890 [ASSURED]
> # STUN ended - Two connections assureds, ports: 44608 and 57890
>
> # Now we try to connect to the VoIP Server source port 44608 and 57890
> ( this might be some ICE related thing, I cannot explain, why my
> client does it, but that's actually not the problem.
> [NEW] 122.XX.115.203:10020 -> 114.XX.234.123 44608 |
> 114.XX.234.123:44608 -> 122.XX.115.203:10020 [UNREPLIED]
> [NEW] 192.168.1.38:57890 -> 122.XX.115.203:10021 |
> 122.XX.115.203:10021 -> 114.XX.234.123:57890 [UNREPLIED]
> # !!!!!!! Look here !!!!!!! That's where it starts! Why do we have a
> port mapping here???
> [NEW] 192.168.1.38:44608 -> 122.XX.115.203:10020 |
> 122.XX.115.203:10020 -> 114.XX.234.123:1030 [UNREPLIED]
> # And from that point on it goes down the drain!
> # Se the port mapping to port 1030!!!???!!!! Why?!
> [UPDATE] 192.168.1.38:44608 -> 122.XX.115.203:10020 |
> 122.XX.115.203:10020 -> 114.XX.234.123:1030
> [UPDATE] 192.168.1.38:44608 -> 122.XX.115.203:10020 |
> 122.XX.115.203:10020 -> 114.XX.234.123:1030 [ASSURED]
> # The connection is assured, because Asterisk is basically listening
> to everything on that port and changes the port it send the data back
> # But my VoIP Provider is not that intelligent. :-((( See the following
> [NEW] 192.168.1.38:44608 -> 62.52.147.185:35642  | 62.52.147.185:35642
> ->114.XX.234.123:1030 [UNREPLIED]
> [NEW] 62.52.147.185:35642 -> 114.XX.234.123:44608 |
> 114.XX.234.123:44608 -> 62.52.147.185:35642 [UNREPLIED]
> [NEW] 62.52.147.185:44609 -> 114.XX.234.123:44609 |
> 114.XX.234.123:44609 -> 62.52.147.185:35643 [UNREPLIED]
> [NEW] 192.168.1.38:57890 -> 62.52.147.185:35643 | 62.52.147.185:35643
> -> 114.XX.234.123:57890 [UNREPLIED]
> -------------------------------------------------------------------------------------------------------------------------------------
> As you can see, half way through ( Underneath my !!!!!!!! comment)
> conntrack/netfilter, linux does a port mapping, and does not use the
> internal port 44608, but mapps the port to port 1030, for whatever
> reason.
> I am pretty sure this port-mapping is unneeded, and it messes up my
> VoIP calls, as the providers are thinking my external port is 44608
> (that's the port the device uses), but linux maps it to port 1030.
> Can anyone technically explain to me why conntrack/netfilter does
> this? Why can't netfilter just do a second mapping (first mapping was
> the one from the STUN connection, line 3)?
>
> This is not a symmetrical NAT!
>
> And please I do my best to explain this, if you need more info or you
> don't understand my explanation, I am willing to give more detailed
> info, or explain it in a different way, but don't be offensive,
> please.
>
> Thanks.


-- 
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il