VoIP conntrack issue

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.

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

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