VoIP conntrack issue

VoIP conntrack issue

[Jörn Krebs]

Hi guys, I got the error, that my last mail hasn't been postet, so I try again:

I know this might have been discussed a thousand times, but actually,
I think, not often enough.
First my situation:
I have a private network, iptables NATed of cause! then I have a
Xen-VoIP-Server(Asterisk) and at last a VoIP provider.
What I like to do is initiate VoIP calls over my VoIP Server and send
the data (RTP audio stream) directly to my provider. The would work
pretty good if ther wasn't my iptables NAT.

What my NAT is doing or what it is not doing is pretty easy:
For some reason my phone (Android CSIPSimple) does a stun lookup on
the same port (source port of the packet) it will later on use for the
RTP VoIP stream. So the Linux conntrack "sees" this successful
connection, and once my phone tries to use the same source port for
the RTP connection to the VoIP server, the conntrack module does a
port mapping ... Which is not needed as we are talking about the UDP
protocol. It is O.K. to use one UDP port with many PC's.
Does anyone know how to change my setup to get this working, or is it
simply impossible. Is conntrack that stupid and cannot handle these
kind od connections (our CISCO router at work doesn't seem to have a
problem with this setup...)

Here is my setup:
Linux NAT Box:
Code:

/sbin/iptables -t nat -A POSTROUTING -j MASQUERADE -s 192.168.0.0/16

(I tried it with SNAT as well, but that doesn't make a difference)

and this is my Conntrack -E log for this connection:
Code:

smartbyte:~ # conntrack -E
# Here is the STUN-Part
[NEW] udp      17 60 src=192.168.1.38 dst=216.93.246.14 sport=44608
dport=3478 [UNREPLIED] src=216.93.246.14 dst=114.XX.234.123 sport=3478
dport=44608
[NEW] udp      17 60 src=192.168.1.38 dst=216.93.246.14 sport=57890
dport=3478 [UNREPLIED] src=216.93.246.14 dst=114.XX.234.123 sport=3478
dport=57890
[UPDATE] udp      17 59 src=192.168.1.38 dst=216.93.246.14 sport=44608
dport=3478 src=216.93.246.14 dst=114.XX.234.123 sport=3478 dport=44608
[UPDATE] udp      17 59 src=192.168.1.38 dst=216.93.246.14 sport=57890
dport=3478 src=216.93.246.14 dst=114.XX.234.123 sport=3478 dport=57890
[UPDATE] udp      17 600 src=192.168.1.38 dst=216.93.246.14
sport=44608 dport=3478 src=216.93.246.14 dst=114.XX.234.123 sport=3478
dport=44608 [ASSURED]
[UPDATE] udp      17 600 src=192.168.1.38 dst=216.93.246.14
sport=57890 dport=3478 src=216.93.246.14 dst=114.XX.234.123 sport=3478
dport=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
[NEW] udp      17 60 src=122.XX.115.203 dst=114.XX.234.123 sport=10020
dport=44608 [UNREPLIED] src=114.XX.234.123 dst=122.XX.115.203
sport=44608 dport=10020
[NEW] udp      17 60 src=192.168.1.38 dst=122.XX.115.203 sport=57890
dport=10021 [UNREPLIED] src=122.XX.115.203 dst=114.XX.234.123
sport=10021 dport=57890
[NEW] udp      17 60 src=192.168.1.38 dst=122.XX.115.203 sport=44608
dport=10020 [UNREPLIED] src=122.XX.115.203 dst=114.XX.234.123
sport=10020 dport=1030
# And from that point on it goes down the drain!
# Se the port mapping to port 1030!!!???!!!! Why?!
[UPDATE] udp      17 59 src=192.168.1.38 dst=122.XX.115.203
sport=44608 dport=10020 src=122.XX.115.203 dst=114.XX.234.123
sport=10020 dport=1030
[UPDATE] udp      17 600 src=192.168.1.38 dst=122.XX.115.203
sport=44608 dport=10020 src=122.XX.115.203 dst=114.XX.234.123
sport=10020 dport=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. :-((( F!
[NEW] udp      17 60 src=192.168.1.38 dst=62.52.147.185 sport=44608
dport=35642 [UNREPLIED] src=62.52.147.185 dst=114.XX.234.123
sport=35642 dport=1030
[NEW] udp      17 60 src=62.52.147.185 dst=114.XX.234.123 sport=35642
dport=44608 [UNREPLIED] src=114.XX.234.123 dst=62.52.147.185
sport=44608 dport=35642
[NEW] udp      17 60 src=62.52.147.185 dst=114.XX.234.123 sport=35643
dport=44609 [UNREPLIED] src=114.XX.234.123 dst=62.52.147.185
sport=44609 dport=35643
[NEW] udp      17 60 src=192.168.1.38 dst=62.52.147.185 sport=57890
dport=35643 [UNREPLIED] src=62.52.147.185 dst=114.XX.234.123
sport=35643 dport=57890

Please can anyone tell me what I am doing wrong? Is ther a switch
somewhere to disable port mapping for the UDP protocol? (And have a
real symmetric NAT?)

Please I need that fixed! Any help appreciated, even if you can point
me to the responsible person for the conntrack module.

Thanks for any answer, SB.

--
Bye Bye, Jörn Krebs

Re: VoIP conntrack issue

[Neal Murphy]

On Monday, November 12, 2012 09:49:49 PM Jörn Krebs wrote:
> Hi guys, I got the error, that my last mail hasn't been postet, so I try
> again:
> 
> I know this might have been discussed a thousand times, but actually,
> I think, not often enough.
> First my situation:
> I have a private network, iptables NATed of cause! then I have a
> Xen-VoIP-Server(Asterisk) and at last a VoIP provider.
> What I like to do is initiate VoIP calls over my VoIP Server and send
> the data (RTP audio stream) directly to my provider. The would work
> pretty good if ther wasn't my iptables NAT.

One possibility is to run siproxd on your firewall (provided your VoIP system 
can use a proxy). This should resolve nearly all VoIP problems related to a 
NATting firewall.

Re: VoIP conntrack issue

[Jörn Krebs]

Not really, as I use the devices behind the firewall, in many
networks, so I need one setup that works.

But to be honest, I don't like to start this discussion:
My question is, why can netfilter not reuse the same port?
The host inside the firewall is the same, so why can't linux manage a
port mapping, which says: If a UDP packet comes from host A to us,
port 1234, AND host B, port 1234, map both to internal host Int1?
(under the assumption, that Int1 tried to establish the connection
with Host A and B first).

The point is: There is NO port mapping clash, why is netfilter
creating one? and does a port remap? (For UDP ... TCP is different.)

On Tue, Nov 13, 2012 at 2:02 PM, Neal Murphy <neal.p.murphy@alum.wpi.edu> wrote:
> On Monday, November 12, 2012 09:49:49 PM Jörn Krebs wrote:
>> Hi guys, I got the error, that my last mail hasn't been postet, so I try
>> again:
>>
>> I know this might have been discussed a thousand times, but actually,
>> I think, not often enough.
>> First my situation:
>> I have a private network, iptables NATed of cause! then I have a
>> Xen-VoIP-Server(Asterisk) and at last a VoIP provider.
>> What I like to do is initiate VoIP calls over my VoIP Server and send
>> the data (RTP audio stream) directly to my provider. The would work
>> pretty good if ther wasn't my iptables NAT.
>
> One possibility is to run siproxd on your firewall (provided your VoIP system
> can use a proxy). This should resolve nearly all VoIP problems related to a
> NATting firewall.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Bye Bye, Jörn Krebs
--------------------------------------------
64 Queen St., Blackstone 4304
Phone: +61731363381
Mobile: +61431068955
Telefon: +495516345347

Re: VoIP conntrack issue

[Eliezer Croitoru]

On 11/13/2012 5:20 AM, Jörn Krebs wrote:
> Not really, as I use the devices behind the firewall, in many
> networks, so I need one setup that works.
>
> But to be honest, I don't like to start this discussion:
> My question is, why can netfilter not reuse the same port?
> The host inside the firewall is the same, so why can't linux manage a
> port mapping, which says: If a UDP packet comes from host A to us,
> port 1234, AND host B, port 1234, map both to internal host Int1?
> (under the assumption, that Int1 tried to establish the connection
> with Host A and B first).
>
> The point is: There is NO port mapping clash, why is netfilter
> creating one? and does a port remap? (For UDP ... TCP is different.)
Are you sure you understand NAT stun and how port prediction works??
Try to talk IP and ports in a diagram that will make sense to the eye 
please.

Regards,
Eliezer

Re: VoIP conntrack issue

[Jörn Krebs]

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.

On Tue, Nov 13, 2012 at 8:32 PM, Eliezer Croitoru <eliezer@ngtech.co.il> wrote:
> On 11/13/2012 5:20 AM, Jörn Krebs wrote:
>>
>> Not really, as I use the devices behind the firewall, in many
>> networks, so I need one setup that works.
>>
>> But to be honest, I don't like to start this discussion:
>> My question is, why can netfilter not reuse the same port?
>> The host inside the firewall is the same, so why can't linux manage a
>> port mapping, which says: If a UDP packet comes from host A to us,
>> port 1234, AND host B, port 1234, map both to internal host Int1?
>> (under the assumption, that Int1 tried to establish the connection
>> with Host A and B first).
>>
>> The point is: There is NO port mapping clash, why is netfilter
>> creating one? and does a port remap? (For UDP ... TCP is different.)
>
> Are you sure you understand NAT stun and how port prediction works??
> Try to talk IP and ports in a diagram that will make sense to the eye
> please.
>
> Regards,
> Eliezer



-- 
Bye Bye, Jörn Krebs
--------------------------------------------
64 Queen St., Blackstone 4304
Phone: +61731363381
Mobile: +61431068955
Telefon: +495516345347

Re: VoIP conntrack issue

[/dev/rob0]

On Tue, Nov 13, 2012 at 10:42:34PM +1100, Jörn Krebs wrote:
> Hi Eliezer,
> 
> I think your comment is a bit offensive, ...

It was not. You need to check your assumptions and place fragile 
sensitivities under guard when posting on a public mailing list for 
help.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: VoIP conntrack issue

[Eliezer Croitoru]

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

Fwd: VoIP conntrack issue

[Jörn Krebs]

Thanks, I really liked your answer that was very helpfull:

I try to explain a few more things to make my situation a bit clearer:
First I have my nice little Android phone (192.168.1.38 here).
That phone operates in different places, like work, home, customer,
etc, so I need one config that fits all
(that's a big problem I know, but I think I solved it for most places,
except my own home network,
which is very odd, as this is the network I am the admin in, and I can
configure everything...)

O.K. so, in this case 192.168.1.38 is my Android phone with CSIPSimple.
My PC/router at home is my old linux system, with kernel 3.4.7, so
fairly recent.
My home network is 192.168.1.0/24
And the public IP address of my home system is: 114.XX.234.123
(That system has two network cards, one internal and one external. But
this system is a router only, I don't want to have any asterisk server
on that system!)

The I have a public Xen VoIP Asterisk server, which actually does a
good job for me: The public IP address is: 122.XX.115.203

And then there is my German VoIP-PSTN-Provider I use to actually do
phone calls to landlines. (GMX).
GMX uses a different IP-address everytime, depending on the region you
call. So I cannot put static rules in my iptables config.

I live in Australia, and what I try to achieve is NOT to route the RTP
traffic through the Asterisk server (which does work perfectly by the
way), because of the extra delay I have with it).
I would like Asterisk to just do the SIP stuff, and when it comes to
the RTP traffic, I want that RTP traffic to go directly from my
Android device to GMX, or any other VoIP provider (I actually have
about 5 different providers, not just GMX)
But most traffic goes over GMX, so it is my aim to get direct RTP
working with GMX.

I don't want to include the conntrack log again, as this doesn't seem
to help explaining the issue.
So I try it in text form here, as this mailing list doesn't allow any
HTML code, so I cannot show that in a graphic.

Here is a list of different connections that are used in this case
(the log I show here is from my linux router box
114.XXXXXXX/192.168.1.1):
1) STUN: My phone connects to the STUN server stun.sipgate.net via UDP
on ports 44608 and 57890, which is shown in the conntrack log as
assured
Phone (src Port 44608) ----------> Router (src Port 44608) ---------->
STUN Server
Phone (src Port 57890) ----------> Router (src Port 57890) ---------->
STUN Server
(STUN Server (dst Port 44608) ----------> Router (src Port 44608)
----------> Phone)
(STUN Server (dst Port 57890) ----------> Router (dst Port 57890)
----------> Phone)


2) SIP: My Android phone connects to the Asterisk server on the SIP
ports (not shown here, as this works fine)
Phone (src Port 5092) ----------> Router (src Port 5092) ----------> SIP Server
(SIP Server (dst Port 5092) ----------> Router (dst Port 5092)
----------> Phone)

3) RTP1: My SIP Server tries to send the RTP traffic back to the
Android phone (initialised from the SIP protocol) to port 44608
(that's the same port that has been used by my phone to connect to the
STUN server !), but that doesn't work, because conntrack/netfilter has
mapped the port 44608, that my phone uses as the src port, to src port
1030 at the router.
Asterisk (DST Port 44608) ----------> Router (DST Port 44608) ------FAILS---->
Phone    (SRC Port 44608) ----------> Router (SRC 1030) ----------> Asterisk
(Asterisk, very intelligent "sees" that wrong port mapping, and rectifies it!!!)
Asterisk (DST Port 1030) ----------> Router (DST 1030) ----------> Phone (44608)

And this is the important point: Why does linux does a port mapping
here? why can't linux just use the same src port externaly that my
phone uses as the src port (44608), when sending data to my asterisk
box?
It re-maps the port my phone uses from 44608 (192.168.1.38) to
external port 1030 (external IP router 114.XXX.XXX.XXX).
(But as I said here, because asterisk is pretty intelligent it "sees"
that and rectifies it's ports. My phone says via the SIP protocol: "I
am on port 44608, please connect me there", but the actual connection
from my phone to the asterisk server comes from port 1030, because my
linux box does a (in my opinion wrong) port mapping), so asterisk
rectifies the dst port from 44608 to 1030, and lives with that. And it
works!

4) RTP2: Now Asterisk tries to "switch" the RTP stream and not be "in
the middle" anymore, and tells GMX to NOT send the RTP data to the
asterisk server anymore, but to the router (the Phone). But because
this is a new connection, asterisk assumes, that this port mapping of
port 44608 to 1030 is for the Asterisk VoIP server only and tells GMX
to use the RTP port 44608 that my Phone is using as it's src port for
sending RTP audio data. At the same time my phone gets the same
inmormation, "Please send the RTP stream directly to the GMX server
Port dst port (35642).
Phone (DST Port 35642, SRC Port 44608) ----------> Router (DST Port
35642, SRC Port 1030)   ----------> GMX (WORKS!) (But one way audio
onlye, because:)
GMX   (SRC Port 35642, DST Port 44608) ----------> Router (SRC Port
35642, DST Port 44608) -----FAILS!----->

See the clash here: The connection should be between: GMX Port 35642
<-----> Phone Port 44608
But because linux is in between and does a port mapping that
connection fails, as linux remaps port 44608 of the port to external
port 1030,

Is that clearer now?
Here is a summary of the UDP connections again (see FAILS for the
errors I have because of the wrong port mapping linux does):
Phone (src Port 44608) ----------> Router (src Port 44608) ---------->
STUN Server
(STUN Server (dst Port 44608) ----------> Router (src Port 44608)
----------> Phone)
Phone (src Port 57890) ----------> Router (src Port 57890) ---------->
STUN Server
(STUN Server (dst Port 57890) ----------> Router (dst Port 57890)
----------> Phone)
Phone (src Port 5092) ----------> Router (src Port 5092) ----------> SIP Server
(SIP Server (dst Port 5092) ----------> Router (dst Port 5092)
----------> Phone)
Asterisk (DST Port 44608) ----------> Router (DST Port 44608) ------FAILS---->
Phone    (SRC Port 44608) ----------> Router (SRC 1030) ----------> Asterisk
Asterisk (DST Port 1030) ----------> Router (DST 1030) ----------> Phone (44608)
Phone (SRC Port 44608) ----------> Router (SRC 1030) ----------> Asterisk
GMX   (SRC Port 35642, DST Port 44608) ----------> Router (DST 44608)
-----FAILS!----->

Please let me know, if you have other questions.
As I said, I can only post Text Mails to this mailing list, so I
cannot provide any nice pictures.
I tried my best to provide text-graphics.

Thanks, Joern.

The conntrack log in a more readable form (hope it comes through):

# 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]

On Wed, Nov 14, 2012 at 7:09 AM, Eliezer Croitoru <eliezer@ngtech.co.il> wrote:
>
> 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

Re: Fwd: VoIP conntrack issue

[Eliezer Croitoru]

Hey Jörn,

As I mentioned before you seems to not understand the NAT and MASQUERADE 
meanings fully.

NAT is only allowing to the router take in account that specific session 
was meant for specific client in the LAN.
means: 192.168.1.38 tries to connect from port 3899 to 1.1.1.1 port 3388 
the router\NAT when will get response  to specific port
then IT will choose(free to choose what it has and like) will then 
forward into LAN ip 192.168.1.38 to port 3899.
What you expect to get is something else not related to STUN or 
NAT(SNAT) but more DNAT or PORT-FORWARDING.
since the asterisk was contacted it will send back to the port it got 
the connection from 1030 which is what was expected and it's not a magic.
When asterisk tells the GMX server to try send you the data the only 
problem is that you dont have corresponding session established with 
your client
which will cause the NAT to not know a thing about it.

The solution is to use DNAT for the specific port forwarding or add UPNP 
service to your linux box that will do it for you.

Regards,
Eliezer


On 11/14/2012 12:49 AM, Jörn Krebs wrote:
 >
 > Hi,
 >
 > the mailing list is not accepting HTML mails, that's why I am sending 
you this directly, as I hope this helps you to understand my problem.
 >
 > ---------- Forwarded message ----------
 > From: Jörn Krebs <jk@smartbyte.de>
 > Date: Wed, Nov 14, 2012 at 9:43 AM
 > Subject: Re: VoIP conntrack issue
 > To: netfilter <netfilter@vger.kernel.org>
 >
 >
 > Thanks, I really liked your answer that was very helpfull:
 >
 > I try to explain a few more things to make my situation a bit clearer:
 > First I have my nice little Android phone (192.168.1.38 here).
 > That phone operates in different places, like work, home, customer, 
etc, so I need one config that fits all
 > (that's a big problem I know, but I think I solved it for most 
places, except my own home network,
 > which is very odd, as this is the network I am the admin in, and I 
can configure everything...)
 >
 > O.K. so, in this case 192.168.1.38 is my Android phone with CSIPSimple.
 > My PC/router at home is my old linux system, with kernel 3.4.7, so 
fairly recent.
 > My home network is 192.168.1.0/24
 > And the public IP address of my home system is: 114.XX.234.123
 > (That system has two network cards, one internal and one external. 
But this system is a router only, I don't want to have any asterisk 
server on that system!)
 >
 > The I have a public Xen VoIP Asterisk server, which actually does a 
good job for me: The public IP address is: 122.XX.115.203
 >
 > And then there is my German VoIP-PSTN-Provider I use to actually do 
phone calls to landlines. (GMX).
 > GMX uses a different IP-address everytime, depending on the region 
you call. So I cannot put static rules in my iptables config.
 >
 > I live in Australia, and what I try to achieve is NOT to route the 
RTP traffic through the Asterisk server (which does work perfectly by 
the way), because of the extra delay I have with it).
 > I would like Asterisk to just do the SIP stuff, and when it comes to 
the RTP traffic, I want that RTP traffic to go directly from my Android 
device to GMX, or any other VoIP provider (I actually have about 5 
different providers, not just GMX)
 > But most traffic goes over GMX, so it is my aim to get direct RTP 
working with GMX.
 >
 > I don't want to include the conntrack log again, as this doesn't seem 
to help explaining the issue.
 > So I try it in text form here, as this mailing list doesn't allow any 
HTML code, so I cannot show that in a graphic.
 >
 > Here is a list of different connections that are used in this case 
(the log I show here is from my linux router box 114.XXXXXXX/192.168.1.1):
 > 1) STUN: My phone connects to the STUN server stun.sipgate.net via 
UDP on ports 44608 and 57890, which is shown in the conntrack log as assured
 > Phone (src Port 44608) ----------> Router (src Port 44608) 
----------> STUN Server
 > Phone (src Port 57890) ----------> Router (src Port 57890) 
----------> STUN Server
 > (STUN Server (dst Port 44608) ----------> Router (src Port 44608) 
----------> Phone)
 > (STUN Server (dst Port 57890) ----------> Router (dst Port 57890) 
----------> Phone)
 >
 >
 > 2) SIP: My Android phone connects to the Asterisk server on the SIP 
ports (not shown here, as this works fine)
 > Phone (src Port 5092) ----------> Router (src Port 5092) ----------> 
SIP Server
 > (SIP Server (dst Port 5092) ----------> Router (dst Port 5092) 
----------> Phone)
 >
 > 3) RTP1: My SIP Server tries to send the RTP traffic back to the 
Android phone (initialised from the SIP protocol) to port 44608 (that's 
the same port that has been used by my phone to connect to the STUN 
server !), but that doesn't work, because conntrack/netfilter has mapped 
the port 44608, that my phone uses as the src port, to src port 1030 at 
the router.
 > Asterisk (DST Port 44608) ----------> Router (DST Port 44608) 
------FAILS---->
 > Phone    (SRC Port 44608) ----------> Router (SRC 1030) ----------> 
Asterisk
 > (Asterisk, very intelligent "sees" that wrong port mapping, and 
rectifies it!!!)
 > Asterisk (DST Port 1030) ----------> Router (DST 1030) ----------> 
Phone (44608)
 >
 > And this is the important point: Why does linux does a port mapping 
here? why can't linux just use the same src port externaly that my phone 
uses as the src port (44608), when sending data to my asterisk box?
 > It re-maps the port my phone uses from 44608 (192.168.1.38) to 
external port 1030 (external IP router 114.XXX.XXX.XXX).
 > (But as I said here, because asterisk is pretty intelligent it "sees" 
that and rectifies it's ports. My phone says via the SIP protocol: "I am 
on port 44608, please connect me there", but the actual connection from 
my phone to the asterisk server comes from port 1030, because my linux 
box does a (in my opinion wrong) port mapping), so asterisk rectifies 
the dst port from 44608 to 1030, and lives with that. And it works!
 >
 > 4) RTP2: Now Asterisk tries to "switch" the RTP stream and not be "in 
the middle" anymore, and tells GMX to NOT send the RTP data to the 
asterisk server anymore, but to the router (the Phone). But because this 
is a new connection, asterisk assumes, that this port mapping of port 
44608 to 1030 is for the Asterisk VoIP server only and tells GMX to use 
the RTP port 44608 that my Phone is using as it's src port for sending 
RTP audio data. At the same time my phone gets the same inmormation, 
"Please send the RTP stream directly to the GMX server Port dst port 
(35642).
 > Phone (DST Port 35642, SRC Port 44608) ----------> Router (DST Port 
35642, SRC Port 1030)   ----------> GMX (WORKS!) (But one way audio 
onlye, because:)
 > GMX   (SRC Port 35642, DST Port 44608) ----------> Router (SRC Port 
35642, DST Port 44608) -----FAILS!----->
 >
 > See the clash here: The connection should be between: GMX Port 35642 
<-----> Phone Port 44608
 > But because linux is in between and does a port mapping that 
connection fails, as linux remaps port 44608 of the port to external 
port 1030,
 >
 > Is that clearer now?
 > Here is a summary of the UDP connections again (see FAILS for the 
errors I have because of the wrong port mapping linux does):
 > Phone (src Port 44608) ----------> Router (src Port 44608) 
----------> STUN Server
 > (STUN Server (dst Port 44608) ----------> Router (src Port 44608) 
----------> Phone)
 > Phone (src Port 57890) ----------> Router (src Port 57890) 
----------> STUN Server
 > (STUN Server (dst Port 57890) ----------> Router (dst Port 57890) 
----------> Phone)
 > Phone (src Port 5092) ----------> Router (src Port 5092) ----------> 
SIP Server
 > (SIP Server (dst Port 5092) ----------> Router (dst Port 5092) 
----------> Phone)
 > Asterisk (DST Port 44608) ----------> Router (DST Port 44608) 
------FAILS---->
 > Phone    (SRC Port 44608) ----------> Router (SRC 1030) ----------> 
Asterisk
 > Asterisk (DST Port 1030) ----------> Router (DST 1030) ----------> 
Phone (44608)
 > Phone (SRC Port 44608) ----------> Router (SRC 1030) ----------> Asterisk
 > GMX   (SRC Port 35642, DST Port 44608) ----------> Router (DST 44608) 
-----FAILS!----->
 >
 > Please let me know, if you have other questions.
 > As I said, I can only post Text Mails to this mailing list, so I 
cannot provide any nice pictures.
 > I tried my best to provide text-graphics.
 >
 > Thanks, Joern.
 >
 > The conntrack log in a more readable form (hope it comes through):
 >
 > # 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]
 >
 > On Wed, Nov 14, 2012 at 7:09 AM, Eliezer Croitoru 
<eliezer@ngtech.co.il> wrote:
 >
 >     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
 >
 >
 >
 >
 >
 > --
 > Bye Bye, Jörn Krebs
 > --------------------------------------------
 > 64 Queen St., Blackstone 4304
 > Phone: +61731363381
 > Mobile: +61431068955
 > Telefon: +495516345347

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



On 11/14/2012 12:51 AM, Jörn Krebs wrote:
> Thanks, I really liked your answer that was very helpfull:
>
> I try to explain a few more things to make my situation a bit clearer:
> First I have my nice little Android phone (192.168.1.38 here).
> That phone operates in different places, like work, home, customer,
> etc, so I need one config that fits all
> (that's a big problem I know, but I think I solved it for most places,
> except my own home network,
> which is very odd, as this is the network I am the admin in, and I can
> configure everything...)
>
> O.K. so, in this case 192.168.1.38 is my Android phone with CSIPSimple.
> My PC/router at home is my old linux system, with kernel 3.4.7, so
> fairly recent.
> My home network is 192.168.1.0/24
> And the public IP address of my home system is: 114.XX.234.123
> (That system has two network cards, one internal and one external. But
> this system is a router only, I don't want to have any asterisk server
> on that system!)
>
> The I have a public Xen VoIP Asterisk server, which actually does a
> good job for me: The public IP address is: 122.XX.115.203
>
> And then there is my German VoIP-PSTN-Provider I use to actually do
> phone calls to landlines. (GMX).
> GMX uses a different IP-address everytime, depending on the region you
> call. So I cannot put static rules in my iptables config.
>
> I live in Australia, and what I try to achieve is NOT to route the RTP
> traffic through the Asterisk server (which does work perfectly by the
> way), because of the extra delay I have with it).
> I would like Asterisk to just do the SIP stuff, and when it comes to
> the RTP traffic, I want that RTP traffic to go directly from my
> Android device to GMX, or any other VoIP provider (I actually have
> about 5 different providers, not just GMX)
> But most traffic goes over GMX, so it is my aim to get direct RTP
> working with GMX.
>
> I don't want to include the conntrack log again, as this doesn't seem
> to help explaining the issue.
> So I try it in text form here, as this mailing list doesn't allow any
> HTML code, so I cannot show that in a graphic.
>
> Here is a list of different connections that are used in this case
> (the log I show here is from my linux router box
> 114.XXXXXXX/192.168.1.1):
> 1) STUN: My phone connects to the STUN server stun.sipgate.net via UDP
> on ports 44608 and 57890, which is shown in the conntrack log as
> assured
> Phone (src Port 44608) ----------> Router (src Port 44608) ---------->
> STUN Server
> Phone (src Port 57890) ----------> Router (src Port 57890) ---------->
> STUN Server
> (STUN Server (dst Port 44608) ----------> Router (src Port 44608)
> ----------> Phone)
> (STUN Server (dst Port 57890) ----------> Router (dst Port 57890)
> ----------> Phone)
>
>
> 2) SIP: My Android phone connects to the Asterisk server on the SIP
> ports (not shown here, as this works fine)
> Phone (src Port 5092) ----------> Router (src Port 5092) ----------> SIP Server
> (SIP Server (dst Port 5092) ----------> Router (dst Port 5092)
> ----------> Phone)
>
> 3) RTP1: My SIP Server tries to send the RTP traffic back to the
> Android phone (initialised from the SIP protocol) to port 44608
> (that's the same port that has been used by my phone to connect to the
> STUN server !), but that doesn't work, because conntrack/netfilter has
> mapped the port 44608, that my phone uses as the src port, to src port
> 1030 at the router.
> Asterisk (DST Port 44608) ----------> Router (DST Port 44608) ------FAILS---->
> Phone    (SRC Port 44608) ----------> Router (SRC 1030) ----------> Asterisk
> (Asterisk, very intelligent "sees" that wrong port mapping, and rectifies it!!!)
> Asterisk (DST Port 1030) ----------> Router (DST 1030) ----------> Phone (44608)
>
> And this is the important point: Why does linux does a port mapping
> here? why can't linux just use the same src port externaly that my
> phone uses as the src port (44608), when sending data to my asterisk
> box?
> It re-maps the port my phone uses from 44608 (192.168.1.38) to
> external port 1030 (external IP router 114.XXX.XXX.XXX).
> (But as I said here, because asterisk is pretty intelligent it "sees"
> that and rectifies it's ports. My phone says via the SIP protocol: "I
> am on port 44608, please connect me there", but the actual connection
> from my phone to the asterisk server comes from port 1030, because my
> linux box does a (in my opinion wrong) port mapping), so asterisk
> rectifies the dst port from 44608 to 1030, and lives with that. And it
> works!
>
> 4) RTP2: Now Asterisk tries to "switch" the RTP stream and not be "in
> the middle" anymore, and tells GMX to NOT send the RTP data to the
> asterisk server anymore, but to the router (the Phone). But because
> this is a new connection, asterisk assumes, that this port mapping of
> port 44608 to 1030 is for the Asterisk VoIP server only and tells GMX
> to use the RTP port 44608 that my Phone is using as it's src port for
> sending RTP audio data. At the same time my phone gets the same
> inmormation, "Please send the RTP stream directly to the GMX server
> Port dst port (35642).
> Phone (DST Port 35642, SRC Port 44608) ----------> Router (DST Port
> 35642, SRC Port 1030)   ----------> GMX (WORKS!) (But one way audio
> onlye, because:)
> GMX   (SRC Port 35642, DST Port 44608) ----------> Router (SRC Port
> 35642, DST Port 44608) -----FAILS!----->
>
> See the clash here: The connection should be between: GMX Port 35642
> <-----> Phone Port 44608
> But because linux is in between and does a port mapping that
> connection fails, as linux remaps port 44608 of the port to external
> port 1030,
>
> Is that clearer now?
> Here is a summary of the UDP connections again (see FAILS for the
> errors I have because of the wrong port mapping linux does):
> Phone (src Port 44608) ----------> Router (src Port 44608) ---------->
> STUN Server
> (STUN Server (dst Port 44608) ----------> Router (src Port 44608)
> ----------> Phone)
> Phone (src Port 57890) ----------> Router (src Port 57890) ---------->
> STUN Server
> (STUN Server (dst Port 57890) ----------> Router (dst Port 57890)
> ----------> Phone)
> Phone (src Port 5092) ----------> Router (src Port 5092) ----------> SIP Server
> (SIP Server (dst Port 5092) ----------> Router (dst Port 5092)
> ----------> Phone)
> Asterisk (DST Port 44608) ----------> Router (DST Port 44608) ------FAILS---->
> Phone    (SRC Port 44608) ----------> Router (SRC 1030) ----------> Asterisk
> Asterisk (DST Port 1030) ----------> Router (DST 1030) ----------> Phone (44608)
> Phone (SRC Port 44608) ----------> Router (SRC 1030) ----------> Asterisk
> GMX   (SRC Port 35642, DST Port 44608) ----------> Router (DST 44608)
> -----FAILS!----->
>
> Please let me know, if you have other questions.
> As I said, I can only post Text Mails to this mailing list, so I
> cannot provide any nice pictures.
> I tried my best to provide text-graphics.
>
> Thanks, Joern.
>
> The conntrack log in a more readable form (hope it comes through):
>
> # 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]
>
> On Wed, Nov 14, 2012 at 7:09 AM, Eliezer Croitoru <eliezer@ngtech.co.il> wrote:
>>
>> 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
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

Re: Fwd: VoIP conntrack issue

[Jörn Krebs]

Hi Eliezer,

I think I missed to explain something here: RTP is not one packet
send, RTP is more like a stream of data,
and with this stream it can happen, that open packet arrives before another.
(That's why the log shows the connection from GMX to my host first,
before my phone sends data to that host, but this is more by luck.
Usually my phone should try to establish a connection to GMX first (so
to say "open" the NAT for that IP port combination), and then GMX
should  send data "back".)

So when I say I have a connection from GMX to my Phone, at the same
time the phone tries to establish a connection the other way around,
but the SIP protocol is managing the ports.
So over SIP both clients (GMX and my phone) agree to operate on
specific ports. Lets say 2000 for GMX and 3000 for my phone.

The firewall is expected to do a symmetric NAT, which means if my
phone sends data to GMX port 2000 and it is using port 3000 as the
source port, it is expected that the router uses the same port as his
external port
.... because, when GMX send it's RTP stream back it will use port 3000
as the destination port (because they agreed on the port in the SIP
session, GMX does not detect the port it gets data from!!!!)
The NAT then should already have a rule, because my internal client of
cause send data to GMX port 2000 using port 3000 as the source port,
because both clients agreed up on in the initial SIP negotiation
phase.
And that's my complaint. Linux is changing the ports. It is using a
different source port for the internal connection to GMX, changing it
to 1030.

This port change is not like a symmetrical NAT should behave, and I
like to know why linux is changing the port and not using the source
port of the client, and how can I avoid this kind of behaviour?

I think you are just looking at the problem from a different angle.

Thanks, Joern.


On Wed, Nov 14, 2012 at 12:08 PM, Eliezer Croitoru <eliezer@ngtech.co.il> wrote:
> Hey Jörn,
>
> As I mentioned before you seems to not understand the NAT and MASQUERADE
> meanings fully.
>
> NAT is only allowing to the router take in account that specific session was
> meant for specific client in the LAN.
> means: 192.168.1.38 tries to connect from port 3899 to 1.1.1.1 port 3388 the
> router\NAT when will get response  to specific port
> then IT will choose(free to choose what it has and like) will then forward
> into LAN ip 192.168.1.38 to port 3899.
> What you expect to get is something else not related to STUN or NAT(SNAT)
> but more DNAT or PORT-FORWARDING.
> since the asterisk was contacted it will send back to the port it got the
> connection from 1030 which is what was expected and it's not a magic.
> When asterisk tells the GMX server to try send you the data the only problem
> is that you dont have corresponding session established with your client
> which will cause the NAT to not know a thing about it.
>
> The solution is to use DNAT for the specific port forwarding or add UPNP
> service to your linux box that will do it for you.
>
> Regards,
> Eliezer
>
>
>
> On 11/14/2012 12:49 AM, Jörn Krebs wrote:
>
>
> Hi,
>
> the mailing list is not accepting HTML mails, that's why I am sending you
> this directly, as I hope this helps you to understand my problem.
>
> ---------- Forwarded message ----------
> From: Jörn Krebs <jk@smartbyte.de>
> Date: Wed, Nov 14, 2012 at 9:43 AM
> Subject: Re: VoIP conntrack issue
> To: netfilter <netfilter@vger.kernel.org>
>
>
> Thanks, I really liked your answer that was very helpfull:
>
> I try to explain a few more things to make my situation a bit clearer:
> First I have my nice little Android phone (192.168.1.38 here).
> That phone operates in different places, like work, home, customer, etc, so
> I need one config that fits all
> (that's a big problem I know, but I think I solved it for most places,
> except my own home network,
> which is very odd, as this is the network I am the admin in, and I can
> configure everything...)
>
> O.K. so, in this case 192.168.1.38 is my Android phone with CSIPSimple.
> My PC/router at home is my old linux system, with kernel 3.4.7, so fairly
> recent.
> My home network is 192.168.1.0/24
> And the public IP address of my home system is: 114.XX.234.123
> (That system has two network cards, one internal and one external. But this
> system is a router only, I don't want to have any asterisk server on that
> system!)
>
> The I have a public Xen VoIP Asterisk server, which actually does a good job
> for me: The public IP address is: 122.XX.115.203
>
> And then there is my German VoIP-PSTN-Provider I use to actually do phone
> calls to landlines. (GMX).
> GMX uses a different IP-address everytime, depending on the region you call.
> So I cannot put static rules in my iptables config.
>
> I live in Australia, and what I try to achieve is NOT to route the RTP
> traffic through the Asterisk server (which does work perfectly by the way),
> because of the extra delay I have with it).
> I would like Asterisk to just do the SIP stuff, and when it comes to the RTP
> traffic, I want that RTP traffic to go directly from my Android device to
> GMX, or any other VoIP provider (I actually have about 5 different
> providers, not just GMX)
> But most traffic goes over GMX, so it is my aim to get direct RTP working
> with GMX.
>
> I don't want to include the conntrack log again, as this doesn't seem to
> help explaining the issue.
> So I try it in text form here, as this mailing list doesn't allow any HTML
> code, so I cannot show that in a graphic.
>
> Here is a list of different connections that are used in this case (the log
> I show here is from my linux router box 114.XXXXXXX/192.168.1.1):
> 1) STUN: My phone connects to the STUN server stun.sipgate.net via UDP on
> ports 44608 and 57890, which is shown in the conntrack log as assured
> Phone (src Port 44608) ----------> Router (src Port 44608) ----------> STUN
> Server
> Phone (src Port 57890) ----------> Router (src Port 57890) ----------> STUN
> Server
> (STUN Server (dst Port 44608) ----------> Router (src Port 44608)
> ----------> Phone)
> (STUN Server (dst Port 57890) ----------> Router (dst Port 57890)
> ----------> Phone)
>
>
> 2) SIP: My Android phone connects to the Asterisk server on the SIP ports
> (not shown here, as this works fine)
> Phone (src Port 5092) ----------> Router (src Port 5092) ----------> SIP
> Server
> (SIP Server (dst Port 5092) ----------> Router (dst Port 5092) ---------->
> Phone)
>
> 3) RTP1: My SIP Server tries to send the RTP traffic back to the Android
> phone (initialised from the SIP protocol) to port 44608 (that's the same
> port that has been used by my phone to connect to the STUN server !), but
> that doesn't work, because conntrack/netfilter has mapped the port 44608,
> that my phone uses as the src port, to src port 1030 at the router.
> Asterisk (DST Port 44608) ----------> Router (DST Port 44608)
> ------FAILS---->
> Phone    (SRC Port 44608) ----------> Router (SRC 1030) ----------> Asterisk
> (Asterisk, very intelligent "sees" that wrong port mapping, and rectifies
> it!!!)
> Asterisk (DST Port 1030) ----------> Router (DST 1030) ----------> Phone
> (44608)
>
> And this is the important point: Why does linux does a port mapping here?
> why can't linux just use the same src port externaly that my phone uses as
> the src port (44608), when sending data to my asterisk box?
> It re-maps the port my phone uses from 44608 (192.168.1.38) to external port
> 1030 (external IP router 114.XXX.XXX.XXX).
> (But as I said here, because asterisk is pretty intelligent it "sees" that
> and rectifies it's ports. My phone says via the SIP protocol: "I am on port
> 44608, please connect me there", but the actual connection from my phone to
> the asterisk server comes from port 1030, because my linux box does a (in my
> opinion wrong) port mapping), so asterisk rectifies the dst port from 44608
> to 1030, and lives with that. And it works!
>
> 4) RTP2: Now Asterisk tries to "switch" the RTP stream and not be "in the
> middle" anymore, and tells GMX to NOT send the RTP data to the asterisk
> server anymore, but to the router (the Phone). But because this is a new
> connection, asterisk assumes, that this port mapping of port 44608 to 1030
> is for the Asterisk VoIP server only and tells GMX to use the RTP port 44608
> that my Phone is using as it's src port for sending RTP audio data. At the
> same time my phone gets the same inmormation, "Please send the RTP stream
> directly to the GMX server Port dst port (35642).
> Phone (DST Port 35642, SRC Port 44608) ----------> Router (DST Port 35642,
> SRC Port 1030)   ----------> GMX (WORKS!) (But one way audio onlye,
> because:)
> GMX   (SRC Port 35642, DST Port 44608) ----------> Router (SRC Port 35642,
> DST Port 44608) -----FAILS!----->
>
> See the clash here: The connection should be between: GMX Port 35642 <----->
> Phone Port 44608
> But because linux is in between and does a port mapping that connection
> fails, as linux remaps port 44608 of the port to external port 1030,
>
> Is that clearer now?
> Here is a summary of the UDP connections again (see FAILS for the errors I
> have because of the wrong port mapping linux does):
> Phone (src Port 44608) ----------> Router (src Port 44608) ----------> STUN
> Server
> (STUN Server (dst Port 44608) ----------> Router (src Port 44608)
> ----------> Phone)
> Phone (src Port 57890) ----------> Router (src Port 57890) ----------> STUN
> Server
> (STUN Server (dst Port 57890) ----------> Router (dst Port 57890)
> ----------> Phone)
> Phone (src Port 5092) ----------> Router (src Port 5092) ----------> SIP
> Server
> (SIP Server (dst Port 5092) ----------> Router (dst Port 5092) ---------->
> Phone)
> Asterisk (DST Port 44608) ----------> Router (DST Port 44608)
> ------FAILS---->
> Phone    (SRC Port 44608) ----------> Router (SRC 1030) ----------> Asterisk
> Asterisk (DST Port 1030) ----------> Router (DST 1030) ----------> Phone
> (44608)
> Phone (SRC Port 44608) ----------> Router (SRC 1030) ----------> Asterisk
> GMX   (SRC Port 35642, DST Port 44608) ----------> Router (DST 44608)
> -----FAILS!----->
>
> Please let me know, if you have other questions.
> As I said, I can only post Text Mails to this mailing list, so I cannot
> provide any nice pictures.
> I tried my best to provide text-graphics.
>
> Thanks, Joern.
>
> The conntrack log in a more readable form (hope it comes through):
>
> # 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]
>
> On Wed, Nov 14, 2012 at 7:09 AM, Eliezer Croitoru <eliezer@ngtech.co.il>
> wrote:
>>
>> 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
>
>
>
>
>
> --
> Bye Bye, Jörn Krebs
> --------------------------------------------
> 64 Queen St., Blackstone 4304
> Phone: +61731363381
> Mobile: +61431068955
> Telefon: +495516345347
>
>
> --
> Eliezer Croitoru
> https://www1.ngtech.co.il
> IT consulting for Nonprofit organizations
> eliezer <at> ngtech.co.il



-- 
Bye Bye, Jörn Krebs
--------------------------------------------
64 Queen St., Blackstone 4304
Phone: +61731363381
Mobile: +61431068955
Telefon: +495516345347

Re: Fwd: VoIP conntrack issue

[Eliezer Croitoru]

Hey Jörn,

You seem to not understand yet what MASQUERADE means.
I have tried to explain it to you but...

NAT is not suppose to do what you are saying but more to allow specific 
function which your usage and UDP protocols in general have problem 
since they based on L2 for each packet which cannot be a basis for 
connection establishment and other part that exists in TCP.

Connection tracking should have capabilities to make things more simple 
in some cases but in this specific case the only full solution will be 
to DNAT the RTP stream.

The best thing I can recommend you that will make sense to you is "how 
nat works"
cisco has a nice doc on it here:
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094831.shtml

look at the category: Dynamic NAT and Overloading Examples.

if the device has static ip in the network from dhcp use iptables with dnat.

Regards,
Eliezer

On 11/14/2012 3:31 AM, Jörn Krebs wrote:
> Hi Eliezer,
>
> I think I missed to explain something here: RTP is not one packet
> send, RTP is more like a stream of data,
> and with this stream it can happen, that open packet arrives before another.
> (That's why the log shows the connection from GMX to my host first,
> before my phone sends data to that host, but this is more by luck.
> Usually my phone should try to establish a connection to GMX first (so
> to say "open" the NAT for that IP port combination), and then GMX
> should  send data "back".)
>
> So when I say I have a connection from GMX to my Phone, at the same
> time the phone tries to establish a connection the other way around,
> but the SIP protocol is managing the ports.
> So over SIP both clients (GMX and my phone) agree to operate on
> specific ports. Lets say 2000 for GMX and 3000 for my phone.
>
> The firewall is expected to do a symmetric NAT, which means if my
> phone sends data to GMX port 2000 and it is using port 3000 as the
> source port, it is expected that the router uses the same port as his
> external port
> .... because, when GMX send it's RTP stream back it will use port 3000
> as the destination port (because they agreed on the port in the SIP
> session, GMX does not detect the port it gets data from!!!!)
> The NAT then should already have a rule, because my internal client of
> cause send data to GMX port 2000 using port 3000 as the source port,
> because both clients agreed up on in the initial SIP negotiation
> phase.
> And that's my complaint. Linux is changing the ports. It is using a
> different source port for the internal connection to GMX, changing it
> to 1030.
>
> This port change is not like a symmetrical NAT should behave, and I
> like to know why linux is changing the port and not using the source
> port of the client, and how can I avoid this kind of behaviour?
>
> I think you are just looking at the problem from a different angle.
>
> Thanks, Joern.

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

Re: VoIP conntrack issue

[Jan Engelhardt]

On Tuesday 2012-11-13 04:20, Jörn Krebs wrote:

>Not really, as I use the devices behind the firewall, in many
>networks, so I need one setup that works.
>
>But to be honest, I don't like to start this discussion:
>My question is, why can netfilter not reuse the same port?

Because the port is still "in use" - in this case, the STUN from earlier

>smartbyte:~ # conntrack -E
># Here is the STUN-Part
>[NEW] udp      17 60 src=192.168.1.38 dst=216.93.246.14
>                     sport=44608 dport=3478 [UNREPLIED]
>                     src=216.93.246.14 dst=114.XX.234.123
>                     sport=3478 dport=44608
>[NEW] udp      17 60 src=192.168.1.38 dst=216.93.246.14
>                     sport=57890 dport=3478 [UNREPLIED]
>                     src=216.93.246.14 dst=114.XX.234.123
>                     sport=3478 dport=57890
>[UPDATE] udp   17 59 src=192.168.1.38 dst=216.93.246.14
>                     sport=44608 dport=3478
>                     src=216.93.246.14 dst=114.XX.234.123
>                     sport=3478 dport=44608
>[UPDATE] udp   17 59 src=192.168.1.38 dst=216.93.246.14
>                     sport=57890 dport=3478
>                     src=216.93.246.14 dst=114.XX.234.123
>                     sport=3478 dport=57890

2x2 STUN probes sent

>[UPDATE] udp  17 600 src=192.168.1.38 dst=216.93.246.14
>                     sport=44608 dport=3478
>                     src=216.93.246.14 dst=114.XX.234.123
>                     sport=3478 dport=44608 [ASSURED]
>[UPDATE] udp  17 600 src=192.168.1.38 dst=216.93.246.14
>                     sport=57890 dport=3478
>                     src=216.93.246.14 dst=114.XX.234.123
>                     sport=3478 dport=57890 [ASSURED]

STUN replies. Note how the timeout for the CT entry is raised to 600
seconds.

># STUN ended - Two connections assureds, ports: 44608 and 57890

NFCT cannot know that. For NFCT, the STUN UDP pseudo-connection
is still (considered) active for another 600 seconds.
However that does not seem to be the issue; more precisely:


># Now we try to connect to the VoIP Server source port 44608 and 57890
>[NEW] udp      17 60 src=122.XX.115.203 dst=114.XX.234.123
>                     sport=10020 dport=44608 [UNREPLIED]
>                     src=114.XX.234.123 dst=122.XX.115.203
>                     sport=44608 dport=10020

Host 122 contacts 114:44608, and there is no mapping done on
this CT. Therefore,
<122.XX.115.203:10020 -- 114.XX.234.123:44608> is now in use.

>[NEW] udp      17 60 src=192.168.1.38 dst=122.XX.115.203
>                     sport=57890 dport=10021 [UNREPLIED]
>                     src=122.XX.115.203 dst=114.XX.234.123
>                     sport=10021 dport=57890
>[NEW] udp      17 60 src=192.168.1.38 dst=122.XX.115.203
>                     sport=44608 dport=10020 [UNREPLIED]
>                     src=122.XX.115.203 dst=114.XX.234.123
>                     sport=10020 dport=1030

<192.168.1.38:44608 -- 122.XX.115.203:10020> would normally be mapped
to <114.XX.234.123:44608 -- 122.XX.115.203:10020> because of your
MASQUERADE rule. However, <114 -- 122> is already taken (see above).

So far that I can see at this time of day.

Re: VoIP conntrack issue

[Jörn Krebs]

Yes, see and that's the point!

Why is there only one port mapping?
That is a very simple NAT. We should have a port mapping by external
IP AND Port.

As an example:
I have internal host A and B and external host C and D

Case 1)
A:1000 -> router:1000 -> C
B:1000 -> router:1000 -> D

Case 2)
A:1000 -> router:1000 -> C
A:1000 -> router:1000 -> D

Case 3)
What doesn't work for obvious reasons is:
A:1000 -> router:1000 -> C
B:1000 -> router:1000 -> C

So can someone please confirm that linux doesn't do Case 1 and Case 2?
And at the same time can someone please give me the email address of
the developer who is responsible for this (incomplete) code?
There are plenty of firewalls/Nat's out there which can cover Case 1&2
and I think it's pretty sad that linux (with it's highly developed
networking stack) is incapable of handling these cases, as this is not
a special case, from my point of view it looks like laziness from the
developer in not supporting this...

Thanks Jan, for the explanation, I was guessing that, but I wasn't
sure as this seems to be missing functionality...
and to be honest I am pretty sure, that there are switches, with which
you can enable that functionality, you just have to know where it
is....


On Wed, Nov 14, 2012 at 12:47 PM, Jan Engelhardt <jengelh@inai.de> wrote:
> On Tuesday 2012-11-13 04:20, Jörn Krebs wrote:
>
>>Not really, as I use the devices behind the firewall, in many
>>networks, so I need one setup that works.
>>
>>But to be honest, I don't like to start this discussion:
>>My question is, why can netfilter not reuse the same port?
>
> Because the port is still "in use" - in this case, the STUN from earlier
>
>>smartbyte:~ # conntrack -E
>># Here is the STUN-Part
>>[NEW] udp      17 60 src=192.168.1.38 dst=216.93.246.14
>>                     sport=44608 dport=3478 [UNREPLIED]
>>                     src=216.93.246.14 dst=114.XX.234.123
>>                     sport=3478 dport=44608
>>[NEW] udp      17 60 src=192.168.1.38 dst=216.93.246.14
>>                     sport=57890 dport=3478 [UNREPLIED]
>>                     src=216.93.246.14 dst=114.XX.234.123
>>                     sport=3478 dport=57890
>>[UPDATE] udp   17 59 src=192.168.1.38 dst=216.93.246.14
>>                     sport=44608 dport=3478
>>                     src=216.93.246.14 dst=114.XX.234.123
>>                     sport=3478 dport=44608
>>[UPDATE] udp   17 59 src=192.168.1.38 dst=216.93.246.14
>>                     sport=57890 dport=3478
>>                     src=216.93.246.14 dst=114.XX.234.123
>>                     sport=3478 dport=57890
>
> 2x2 STUN probes sent
>
>>[UPDATE] udp  17 600 src=192.168.1.38 dst=216.93.246.14
>>                     sport=44608 dport=3478
>>                     src=216.93.246.14 dst=114.XX.234.123
>>                     sport=3478 dport=44608 [ASSURED]
>>[UPDATE] udp  17 600 src=192.168.1.38 dst=216.93.246.14
>>                     sport=57890 dport=3478
>>                     src=216.93.246.14 dst=114.XX.234.123
>>                     sport=3478 dport=57890 [ASSURED]
>
> STUN replies. Note how the timeout for the CT entry is raised to 600
> seconds.
>
>># STUN ended - Two connections assureds, ports: 44608 and 57890
>
> NFCT cannot know that. For NFCT, the STUN UDP pseudo-connection
> is still (considered) active for another 600 seconds.
> However that does not seem to be the issue; more precisely:
>
>
>># Now we try to connect to the VoIP Server source port 44608 and 57890
>>[NEW] udp      17 60 src=122.XX.115.203 dst=114.XX.234.123
>>                     sport=10020 dport=44608 [UNREPLIED]
>>                     src=114.XX.234.123 dst=122.XX.115.203
>>                     sport=44608 dport=10020
>
> Host 122 contacts 114:44608, and there is no mapping done on
> this CT. Therefore,
> <122.XX.115.203:10020 -- 114.XX.234.123:44608> is now in use.
>
>>[NEW] udp      17 60 src=192.168.1.38 dst=122.XX.115.203
>>                     sport=57890 dport=10021 [UNREPLIED]
>>                     src=122.XX.115.203 dst=114.XX.234.123
>>                     sport=10021 dport=57890
>>[NEW] udp      17 60 src=192.168.1.38 dst=122.XX.115.203
>>                     sport=44608 dport=10020 [UNREPLIED]
>>                     src=122.XX.115.203 dst=114.XX.234.123
>>                     sport=10020 dport=1030
>
> <192.168.1.38:44608 -- 122.XX.115.203:10020> would normally be mapped
> to <114.XX.234.123:44608 -- 122.XX.115.203:10020> because of your
> MASQUERADE rule. However, <114 -- 122> is already taken (see above).
>
> So far that I can see at this time of day.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Bye Bye, Jörn Krebs
--------------------------------------------
64 Queen St., Blackstone 4304
Phone: +61731363381
Mobile: +61431068955
Telefon: +495516345347

Re: VoIP conntrack issue

[Jan Engelhardt]

On Wednesday 2012-11-14 03:35, Jörn Krebs wrote:

>>># Now we try to connect to the VoIP Server source port 44608 and 57890
>>>[NEW] udp      17 60 src=122.XX.115.203 dst=114.XX.234.123
>>>                     sport=10020 dport=44608 [UNREPLIED]
>>>                     src=114.XX.234.123 dst=122.XX.115.203
>>>                     sport=44608 dport=10020
>>
>> Host 122 contacts 114:44608, and there is no mapping done on
>> this CT. Therefore,
>> <122.XX.115.203:10020 -- 114.XX.234.123:44608> is now in use.
>>
>>>[NEW] udp      17 60 src=192.168.1.38 dst=122.XX.115.203
>>>                     sport=44608 dport=10020 [UNREPLIED]
>>>                     src=122.XX.115.203 dst=114.XX.234.123
>>>                     sport=10020 dport=1030
>>
>> <192.168.1.38:44608 -- 122.XX.115.203:10020> would normally be mapped
>> to <114.XX.234.123:44608 -- 122.XX.115.203:10020> because of your
>> MASQUERADE rule. However, <114:44608 -- 122:10020>
>> is already taken (see above).
>
>Why is there only one port mapping?

#  <-> both ways

First, you only used one MASQUERADE rule, which says to establish a
mapping 192.168.1.38:P <-> 114.XX.234.123:Q, if and only if,
192.168.0.0/16 is the src address on the initiating packet. This is
not the case for that <122.XX.115.203:10020->114.XX.234.123:44608>
packet of yours.
In weird Wikipedia terms, nf_nat implements "Cone NAT" exclusively.

There are two ways here.

1.
`modprobe nf_nat_sip` and see if that yields the desired result.


If not,

2.
To get the "1:1 NAT", you will need to add a "second" cone in the
other direction, so to speak. This is then something like

 iptables -t nat -A PREROUTING -i internet [-d 114.XX.234.123] \
          -j DNAT --to 192.168.1.38

As you no doubt will notice, this makes the router as a host 
inaccessible on 114.XX.234.123, but that's what 1:1 means.

HTH.

Re: VoIP conntrack issue

[Eliezer Croitoru]

Or instead just use DNAT with specific ports that will allow any other 
traffic from this host to others based on basic NAT what called 
"port-forwarding"

Regards,
Eliezer

On 11/14/2012 1:23 PM, Jan Engelhardt wrote:
> #  <-> both ways
>
> First, you only used one MASQUERADE rule, which says to establish a
> mapping 192.168.1.38:P <-> 114.XX.234.123:Q, if and only if,
> 192.168.0.0/16 is the src address on the initiating packet. This is
> not the case for that <122.XX.115.203:10020->114.XX.234.123:44608>
> packet of yours.
> In weird Wikipedia terms, nf_nat implements "Cone NAT" exclusively.
>
> There are two ways here.
>
> 1.
> `modprobe nf_nat_sip` and see if that yields the desired result.
>
>
> If not,
>
> 2.
> To get the "1:1 NAT", you will need to add a "second" cone in the
> other direction, so to speak. This is then something like
>
>   iptables -t nat -A PREROUTING -i internet [-d 114.XX.234.123] \
>            -j DNAT --to 192.168.1.38
>
> As you no doubt will notice, this makes the router as a host
> inaccessible on 114.XX.234.123, but that's what 1:1 means.
>
> HTH.

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

Re: VoIP conntrack issue

[Jan Engelhardt]

On Wednesday 2012-11-14 16:38, Eliezer Croitoru wrote:

>Or instead just use DNAT with specific ports that will allow any other 
>traffic from this host to others based on basic NAT what called 
>"port-forwarding"

Port forwarding is a terrible misnomer, because the port itself is an 
entity belonging to the host, and as such static. NA(P)T, or "port 
mapping" if you have to, is just fine and catches the spirit properly. 
If you need a car analogy, you can't move the piers/ports either, only 
the ships.

That said, DNAT is exactly what I gave as one way of resolution. From 
there, one can use --dport(s) as needed, but then that's not a full 1:1 
NAT anymore.
(I get the feeling my mail was ignored, perhaps you should go through 
the text and bottom post like everybody else.)

>>  iptables -t nat -A PREROUTING -i internet [-d 114.XX.234.123] \
>>           -j DNAT --to 192.168.1.38

Re: VoIP conntrack issue

[Eliezer Croitoru]

On 11/14/2012 5:54 PM, Jan Engelhardt wrote:
> On Wednesday 2012-11-14 16:38, Eliezer Croitoru wrote:
>
>> >Or instead just use DNAT with specific ports that will allow any other
>> >traffic from this host to others based on basic NAT what called
>> >"port-forwarding"
> Port forwarding is a terrible misnomer, because the port itself is an
> entity belonging to the host, and as such static. NA(P)T, or "port
> mapping" if you have to, is just fine and catches the spirit properly.
> If you need a car analogy, you can't move the piers/ports either, only
> the ships.
>
> That said, DNAT is exactly what I gave as one way of resolution. From
> there, one can use --dport(s) as needed, but then that's not a full 1:1
> NAT anymore.
> (I get the feeling my mail was ignored, perhaps you should go through
> the text and bottom post like everybody else.)
>
>>> >>  iptables -t nat -A PREROUTING -i internet [-d 114.XX.234.123] \
>>> >>           -j DNAT --to 192.168.1.38

Since he has very specific problem I suggested to do that which extends 
your saying.
By the way you spelled it better then me..

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

Re: VoIP conntrack issue

[Jörn Krebs]

Hi guys,

sorry, but you didn't get my point:
The most advanced networking operating system is not capable of doing
symetric NAT?
That's bad. that's just plain bad.

I will try to get someone on the development list.
I am working for a big company ( which does not rely on this, that's
my private stuff, luckily),
but if we would do this kind of incomplete Development (not
implementing the symetric NAT functionality, although we obviously
know, that it would make things work better),
we would be in trouble. Sadly no one does pick up the point in this,
that there is some missing functionality.

Thanks for you advice with using static mappings, but that doesn't
work, as I cannot predict which ports my phone will use.
(I did that trick with two phones I have at home, but it will never
work with my mobile, so that isn't a solution.)

Thanks guys, and bye.

On Thu, Nov 15, 2012 at 3:01 AM, Eliezer Croitoru <eliezer@ngtech.co.il> wrote:
> On 11/14/2012 5:54 PM, Jan Engelhardt wrote:
>>
>> On Wednesday 2012-11-14 16:38, Eliezer Croitoru wrote:
>>
>>> >Or instead just use DNAT with specific ports that will allow any other
>>> >traffic from this host to others based on basic NAT what called
>>> >"port-forwarding"
>>
>> Port forwarding is a terrible misnomer, because the port itself is an
>> entity belonging to the host, and as such static. NA(P)T, or "port
>> mapping" if you have to, is just fine and catches the spirit properly.
>> If you need a car analogy, you can't move the piers/ports either, only
>> the ships.
>>
>> That said, DNAT is exactly what I gave as one way of resolution. From
>> there, one can use --dport(s) as needed, but then that's not a full 1:1
>> NAT anymore.
>> (I get the feeling my mail was ignored, perhaps you should go through
>> the text and bottom post like everybody else.)
>>
>>>> >>  iptables -t nat -A PREROUTING -i internet [-d 114.XX.234.123] \
>>>> >>           -j DNAT --to 192.168.1.38
>
>
> Since he has very specific problem I suggested to do that which extends your
> saying.
> By the way you spelled it better then me..
>
> Regards,
> Eliezer
>
> --
> Eliezer Croitoru
> https://www1.ngtech.co.il
> IT consulting for Nonprofit organizations
> eliezer <at> ngtech.co.il



-- 
Bye Bye, Jörn Krebs
--------------------------------------------
64 Queen St., Blackstone 4304
Phone: +61731363381
Mobile: +61431068955
Telefon: +495516345347

VoIP conntrack issue

[Jörn Krebs]

Hi guys,

I have an issue, and I need a full symmetric NAT router (I already
posted that on the users list).

I use this for VoIP UDP only connections, so it doesn't have to work with TCP!
To make it short I need to cover the following first two NAT cases
(which is called symetric NAT)

Case 1)
A:5000 <-> router:5000 <-> C
A:5000 <-> router:5000 <-> D

Case 2)
A:5000 <-> router:5000 <-> C
B:5000 <-> router:5000 <-> D

Case 3)
What doesn't work for obvious reasons is:
A:5000 <-> router:5000 <-> C
B:5000 <-> router:5000 <-> C


The problem I have with case 1 is that Linux is assigning a new external port.
So and my router Case 1 looks more like this:
A:5000 <-> router:5000 <-> C
A:5000 <-> router:1030 <-> D
Which causes a big issue with my VoIP setup!
(VoIP is negotiating the ports inside the SIP protocol. They are not
detected and they are fixed and not detected on the fly)

Is there any flag or anything else I can do or setup up to make my
Linux router to be able to cover Case 1 & esp. 2 for UDP?
So can some developer help me?

Short SIP intro of what is going on, and why I need to re-use a port number.
1) Client A -> (router) -> VoIP Server (RTP port of Client A defined
here, lets say 3000)

2) VoIP Server -> VoIP Provider (RTP port of Provider defined here,
lets say 4000)

3) VoIP Server -> (router) -> Client A (defines local Temp RTP Port
lets say 5001)

4) VoIP Server -> (router) -> VoIP Provider (defines local Temp RTP
Portlets say 5002)

5) RTP flow is: Client A:3000 <-> (router):3000 <-> 5001:Voip
Server:5002 -> VoIP Provider:4000 (Uhhh this is dodgy an unneded)
    We now try to set up Client A -> (router) -> VoIP Provider (for
the RTP stream)

6) VoIP Server -> (router) -> Client A (tells Client A the RTP data
which is IPAdr:4000 of VoIP Provider)

7) VoIP Server -> VoIP Provider (tells VoIP Provider the RTP data
which is IPAdr:3000 of Client A)

8) Client A:3000 -> (router):1025 -> VoIP Provider:4000 (but because
we reuse the same port from 1) netfilter does a port remapping so uses
a different external port, as it thinks it is taken by a different
connection...)

9) VoIP Provider:4000 -> (router):3000  (Gets rejected because the
known RTP port is used for the connection with the VoIP Server, and
the connection from Client A -> VoIP provider has been remapped to a
different port (1025 in this case), which is unknown to the VoIP
provider so the connection fails)

(Hope I made my case clear)

--
Bye Bye, Jörn Krebs
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: VoIP conntrack issue

[Jan Engelhardt]

On Wednesday 2012-11-14 23:41, Jörn Krebs wrote:
>
>The problem I have with case 1 is that Linux is assigning a new external port.
>So and my router Case 1 looks more like this:
>A:5000 <-> router:5000 <-> C
>A:5000 <-> router:1030 <-> D
>Which causes a big issue with my VoIP setup!
>(VoIP is negotiating the ports inside the SIP protocol. They are not
>detected and they are fixed and not detected on the fly)

Are you sure you have tried loading nf_nat_sip, like I mentioned
in the thread[1] on netfilter@ ? Or the extra DNAT rule?

[1] http://marc.info/?l=netfilter&m=135289221821117&w=2

>(Hope I made my case clear)

(The conntrack -E dump made a lot more sense to me.)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: VoIP conntrack issue

[Jörn Krebs]

Hi,

I think you don't get the point. I have many devices that are
connecting to the same servers(n:m connections),
so I cannot put any simple rule in there. Esp. because the GMX Server
which is the second one that connects and is changing port and IP
address all the time,
my internal phone is changing the port, and might even change it's IP,
so I cannot define a rule based on that.
(I have mentioned that in my first post: It is working, but not when I
like to use direct rtp, which for some reason is possible in every
other network I am working in (mostly Cisco routers), but not in my
own one, and because linux should be / is highly configurable I
though, that this feature just has to be enabled somehow (with feature
I mean a real symmetric NAT))

So I don't want to do "hard" changes that would one work in one situation.

Yes I always have nf_nat_sip compiled in my kernel. It might have
helped, but in this specific case (which isn't specific in VoIP at
all, it's basically a standard case in that world), it doesn't seem to
work.

I WANT A SYMMETRIC NAT!!!! -> Why doesn't anybody understand that?
I mean I am on the netfilter list. Everyone here should know what I
mean with the term symmetric NAT, so what is the problem?
I more and more got the impression, that you are developing in your
own little world, and not the world where we have different types of
NAT.
Most of them can be covered with netfilter/conntrack, but some cannot
and I don't think it can be very hard to implement a symmetric NAT,
can it?

Please advise me on how to implement a symmetric NAT with iptables.

What does the random flag for example on iptables do?

What is the difference between MASQUERADE and SNAT?
Is there any option I can give to the conntrack modules that might
change anything?

Thanks, Joern.

On Thu, Nov 15, 2012 at 10:38 AM, Jan Engelhardt <jengelh@inai.de> wrote:
>
> On Wednesday 2012-11-14 23:41, Jörn Krebs wrote:
>>
>>The problem I have with case 1 is that Linux is assigning a new external port.
>>So and my router Case 1 looks more like this:
>>A:5000 <-> router:5000 <-> C
>>A:5000 <-> router:1030 <-> D
>>Which causes a big issue with my VoIP setup!
>>(VoIP is negotiating the ports inside the SIP protocol. They are not
>>detected and they are fixed and not detected on the fly)
>
> Are you sure you have tried loading nf_nat_sip, like I mentioned
> in the thread[1] on netfilter@ ? Or the extra DNAT rule?
>
> [1] http://marc.info/?l=netfilter&m=135289221821117&w=2
>
>>(Hope I made my case clear)
>
> (The conntrack -E dump made a lot more sense to me.)
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Bye Bye, Jörn Krebs
--------------------------------------------
64 Queen St., Blackstone 4304
Phone: +61731363381
Mobile: +61431068955
Telefon: +495516345347

Re: VoIP conntrack issue

[Payam Chychi]

policy based routing + nat ...?


Sent from my iPhone

On 2012-11-14, at 4:15 PM, Jörn Krebs <jk@smartbyte.de> wrote:

> Hi,
> 
> I think you don't get the point. I have many devices that are
> connecting to the same servers(n:m connections),
> so I cannot put any simple rule in there. Esp. because the GMX Server
> which is the second one that connects and is changing port and IP
> address all the time,
> my internal phone is changing the port, and might even change it's IP,
> so I cannot define a rule based on that.
> (I have mentioned that in my first post: It is working, but not when I
> like to use direct rtp, which for some reason is possible in every
> other network I am working in (mostly Cisco routers), but not in my
> own one, and because linux should be / is highly configurable I
> though, that this feature just has to be enabled somehow (with feature
> I mean a real symmetric NAT))
> 
> So I don't want to do "hard" changes that would one work in one situation.
> 
> Yes I always have nf_nat_sip compiled in my kernel. It might have
> helped, but in this specific case (which isn't specific in VoIP at
> all, it's basically a standard case in that world), it doesn't seem to
> work.
> 
> I WANT A SYMMETRIC NAT!!!! -> Why doesn't anybody understand that?
> I mean I am on the netfilter list. Everyone here should know what I
> mean with the term symmetric NAT, so what is the problem?
> I more and more got the impression, that you are developing in your
> own little world, and not the world where we have different types of
> NAT.
> Most of them can be covered with netfilter/conntrack, but some cannot
> and I don't think it can be very hard to implement a symmetric NAT,
> can it?
> 
> Please advise me on how to implement a symmetric NAT with iptables.
> 
> What does the random flag for example on iptables do?
> 
> What is the difference between MASQUERADE and SNAT?
> Is there any option I can give to the conntrack modules that might
> change anything?
> 
> Thanks, Joern.
> 
> On Thu, Nov 15, 2012 at 10:38 AM, Jan Engelhardt <jengelh@inai.de> wrote:
>> 
>> On Wednesday 2012-11-14 23:41, Jörn Krebs wrote:
>>> 
>>> The problem I have with case 1 is that Linux is assigning a new external port.
>>> So and my router Case 1 looks more like this:
>>> A:5000 <-> router:5000 <-> C
>>> A:5000 <-> router:1030 <-> D
>>> Which causes a big issue with my VoIP setup!
>>> (VoIP is negotiating the ports inside the SIP protocol. They are not
>>> detected and they are fixed and not detected on the fly)
>> 
>> Are you sure you have tried loading nf_nat_sip, like I mentioned
>> in the thread[1] on netfilter@ ? Or the extra DNAT rule?
>> 
>> [1] http://marc.info/?l=netfilter&m=135289221821117&w=2
>> 
>>> (Hope I made my case clear)
>> 
>> (The conntrack -E dump made a lot more sense to me.)
>> --
>> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> -- 
> Bye Bye, Jörn Krebs
> --------------------------------------------
> 64 Queen St., Blackstone 4304
> Phone: +61731363381
> Mobile: +61431068955
> Telefon: +495516345347
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: VoIP conntrack issue

[Jan Engelhardt]

On Thursday 2012-11-15 01:15, Jörn Krebs wrote:

>Hi,
>
>I think you don't get the point.

I really think I don't. Which means your description was too convoluted.

>I WANT A SYMMETRIC NAT!!!! -> Why doesn't anybody understand that?
>I mean I am on the netfilter list. Everyone here should know what I
>mean with the term symmetric NAT

NF does not use these terms, so no. WP also warns about the problems
with the term in http://en.wikipedia.org/wiki/Symmetric_NAT .

Fact is outgoing streams don't magically add mappings for incoming ones, 
unless you use a nf_conntrack_* module that explicitly does it.

There's no nf_conntrack_stun, so if your STUN exchange with
216.x.y.z:3478 causes a non-participant, 134.76.13.21, to suddenly
start sending packets to 114.x.y.z:44608, it's only logical all signs
show a red warning light "unsolicited connection attempt".

>I more and more got the impression, that you are developing in your
>own little world, and not the world where we have different types of
>NAT.

We don't even think "types of NAT". We think in absolute
{a:b, c:d} tuples.

Symmetric relation  x R y => y R x  makes everybody's heads hurt,
because it is not obvious if x is {ip,port} or {ip,port,ip,port}
or just {port,port}.


Dammit, I wasted too much time on this.

Re: VoIP conntrack issue

[Eliezer Croitoru]

On 11/15/2012 7:04 AM, Jan Engelhardt wrote:
> Dammit, I wasted too much time on this.
So what do you do?
I work on something really fun.
NAT has been explained more then once here.

Re: VoIP conntrack issue

[Jörn Krebs]

Hi there,

On Thu, Nov 15, 2012 at 4:04 PM, Jan Engelhardt <jengelh@inai.de> wrote:
> On Thursday 2012-11-15 01:15, Jörn Krebs wrote:
>
>>Hi,
>>
>>I think you don't get the point.
>
> I really think I don't. Which means your description was too convoluted.
Yes, maybe I should describe it even easier, so you understand it...

>>I WANT A SYMMETRIC NAT!!!! -> Why doesn't anybody understand that?
>>I mean I am on the netfilter list. Everyone here should know what I
>>mean with the term symmetric NAT
>
> NF does not use these terms, so no. WP also warns about the problems
> with the term in http://en.wikipedia.org/wiki/Symmetric_NAT .
No, he does not, he warns that people use it, although they have no
clue what they are talking about, well that's not the case here.

But let me state that even simpler:
192.168.1.38 is the internal host
router is the router (with iptables nf and conntrack on it, and an
iptables MASQUERADE or SNAT rule)
123.0.0.1 is the external host
234.0.0.1 is the second external host

I will show the packets in the sequence they are send out:
Netfilter/Conntrack should do the following, protocol is UDP:
192.168.1.38:1234      -> router:1234 -> 123.0.0.1:4321
123.0.0.1:4321           -> router:1234 -> 192.168.1.38:1234
192.168.1.38:1234      -> router:1234 -> 234.0.0.1:5678
234.0.0.1:5678           -> router:1234 -> 192.168.1.38:1234

That doesn't work, because for some unknown reason netfilter/conntrack
creates a mapping for port 1234 for the external host 123.123.123.123,
and cannot create a second mapping for port 1234 for the external host
234.234.234.234.
It has to change the port in between.

What happens is (and this has nothing to do with STUN!)
192.168.1.38:1234      -> router:1234 -> 123.0.0.1:4321
123.0.0.1:4321           -> router:1234 -> 192.168.1.38:1234
192.168.1.38:1234      -> router:1025 -> 234.0.0.1:5678
234.0.0.1:5678           -> router:1234 (FAILS!!!!)

To be clear:
192.168.1.38:1234      -> router:1025 -> 234.0.0.1:5678
(In this case the linux router should not use port 1025, but use port
1234, as this was the port used by the internal host)
234.0.0.1:5678           -> router:1234 (FAILS!!!!)
(This is just the consequence of the wrong mapping!)

> Fact is outgoing streams don't magically add mappings for incoming ones,
> unless you use a nf_conntrack_* module that explicitly does it.
The NAT module does that, am I right?

> There's no nf_conntrack_stun, so if your STUN exchange with
(I cut off here, this should be "normal" NAT behaviour and has nothing
to do with STUN.)

>>I more and more got the impression, that you are developing in your
>>own little world, and not the world where we have different types of
>>NAT.
>
> We don't even think "types of NAT". We think in absolute > {a:b, c:d} tuples.
Well, but you should know what a symmetric NAT is?
You are complaining about my description not beeing accurate, and at
the same time you are sending me links to WIKI pages, where the
correct description can be found.
So, you are investing more time in finding reasons not to help, than
actually recognize the problem and help!

So what are {a:b, c:d} tuples? Is a the ip and b the port? If it that
easy, see my description above, I am nearly using these terms there.)

Thanks, Joern.