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@xxxxxxxxxxxx>
> Date: Wed, Nov 14, 2012 at 9:43 AM
> Subject: Re: VoIP conntrack issue
> To: netfilter <netfilter@xxxxxxxxxxxxxxx>
>
>
> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
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
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
