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