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
