3 Dec
2004
3 Dec
'04
12:25 a.m.
Hi,
I am thinking about having more NAT test on a sip packet. Just want to find
out if it is useful.
I run into some situations that some 'smart' UAs try to detect its external
IP and put the external IP address into the sip packet. Depending on the
network and NAT firewall setup, it may or may not set the right external IP
and port in the packet. If it is not, but pretends to be on the public
internet, then there is most likely a one-way voice or no voice issue. I'd
like to be able to detect and force it to use a nat proxy. By checking these
packets, I found that the only trace is the private IP address in the
call-id header field. It will be useful to check if a RFC1918 address is
used in the call-id. I understand that it is not a thorough test for NAT,
well, just like any other NAT test.
Can someone please comment if it is a good test?
Thanks,
Richard
3 Dec
3 Dec
10 a.m.
nat test based on rfc1918 address in call-id fieldIf I understand you correctly, you are
talking about test 16 found in nathelper cvs. You may want to have a look at that test
first. You call nat_uac-test("19") to trigger the test.
g-)
---- Original Message ----
From: Richard
To: serusers(a)lists.iptel.org
Sent: Thursday, December 02, 2004 10:25 PM
Subject: [Serusers] nat test based on rfc1918 address in call-id field
Hi,
I am thinking about having more NAT test on a sip packet. Just want
to find out if it is useful.
I run into some situations that some 'smart' UAs try to detect its
external IP and put the external IP address into the sip packet.
Depending on the network and NAT firewall setup, it may or may not
set the right external IP and port in the packet. If it is not, but
pretends to be on the public internet, then there is most likely a
one-way voice or no voice issue. I'd like to be able to detect and
force it to use a nat proxy. By checking these packets, I found that
the only trace is the private IP address in the call-id header field.
It will be useful to check if a RFC1918 address is used in the
call-id. I understand that it is not a thorough test for NAT, well,
just like any other NAT test.
Can someone please comment if it is a good test?
Thanks,
Richard
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
10:32 a.m.
________________________________________
From: Greger V. Teigre [mailto:greger@teigre.com]
Sent: Thursday, December 02, 2004 9:00 PM
To: Richard; serusers(a)lists.iptel.org
Subject: Re: [Serusers] nat test based on rfc1918 address in call-id field
If I understand you correctly, you are talking about
test 16 found in
nathelper cvs.
You may want to have a look at that test first. You
call
nat_uac-test("19") to
trigger the test.
g-)
eh
test 16 is different
it tests if the source port is different from the
port in Via.
The proposed test checks the private ip in Call-ID field.
> Hi,
> I am thinking about having more NAT test on a sip packet. Just want
> to find out if it is useful.
> I run into some situations that some smart UAs try to detect its
> external IP and put the external IP address into the sip packet.
> Depending on the network and NAT firewall setup, it may or may not
> set the right external IP and port in the packet. If it is not, but
> pretends to be on the public internet, then there is most likely a
> one-way voice or no voice issue. Id like to be able to detect and
> force it to use a nat proxy. By checking these packets, I found that
> the only trace is the private IP address in the call-id header field.
> It will be useful to check if a RFC1918 address is used in the
> call-id. I understand that it is not a thorough test for NAT, well,
> just like any other NAT test.
> Can someone please comment if it is a good test?
11:44 a.m.
Sorry. I was a bit quick there. Do you have any particular UAs/scenarios in
mind where this test will be more appropriate than the existing?
g-)
Richard wrote:
________________________________________
From: Greger V. Teigre [mailto:greger@teigre.com]
Sent: Thursday, December 02, 2004 9:00 PM
To: Richard; serusers(a)lists.iptel.org
Subject: Re: [Serusers] nat test based on rfc1918 address in call-id
field
If I understand you correctly, you are talking
about test 16 found
in nathelper cvs. You may want to have a look at that test first.
You call nat_uac-test("19") to trigger the test.
g-)
eh. test 16 is different. it tests if the source port is different
from the port in Via.
The proposed test checks the private ip in Call-ID field.
>> Hi,
>> I am thinking about having more NAT test on a sip packet. Just want
>> to find out if it is useful.
>> I run into some situations that some 'smart' UAs try to detect its
>> external IP and put the external IP address into the sip packet.
>> Depending on the network and NAT firewall setup, it may or may not
>> set the right external IP and port in the packet. If it is not, but
>> pretends to be on the public internet, then there is most likely a
>> one-way voice or no voice issue. I'd like to be able to detect and
>> force it to use a nat proxy. By checking these packets, I found that
>> the only trace is the private IP address in the call-id header
>> field. It will be useful to check if a RFC1918 address is used in
>> the call-id. I understand that it is not a thorough test for NAT,
>> well, just like any other NAT test.
>> Can someone please comment if it is a good test?
11:52 a.m.
-----Original Message-----
From: Greger V. Teigre [mailto:greger@teigre.com]
Sent: Thursday, December 02, 2004 10:45 PM
To: Richard; serusers(a)lists.iptel.org
Subject: Re: [Serusers] nat test based on rfc1918 address in call-id field
Sorry. I was a bit quick there. Do you have any particular UAs/scenarios
in
mind where this test will be more appropriate than the existing?
g-)
Stun doesn't work well with linux firewall.
http://www.netfilter.org/documentation/conferences/nf-workshop-2004-summary.
html#AEN106
Richard wrote:
> ________________________________________
> From: Greger V. Teigre [mailto:greger@teigre.com]
> Sent: Thursday, December 02, 2004 9:00 PM
> To: Richard; serusers(a)lists.iptel.org
> Subject: Re: [Serusers] nat test based on rfc1918 address in call-id
> field
>
>> If I understand you correctly, you are talking about test 16 found
>> in nathelper cvs. You may want to have a look at that test first.
>> You call nat_uac-test("19") to trigger the test.
>> g-)
>
> eh. test 16 is different. it tests if the source port is different
> from the port in Via.
>
> The proposed test checks the private ip in Call-ID field.
>
>>> Hi,
>>> I am thinking about having more NAT test on a sip packet. Just want
>>> to find out if it is useful.
>>> I run into some situations that some 'smart' UAs try to detect its
>>> external IP and put the external IP address into the sip packet.
>>> Depending on the network and NAT firewall setup, it may or may not
>>> set the right external IP and port in the packet. If it is not, but
>>> pretends to be on the public internet, then there is most likely a
>>> one-way voice or no voice issue. I'd like to be able to detect and
>>> force it to use a nat proxy. By checking these packets, I found that
>>> the only trace is the private IP address in the call-id header
>>> field. It will be useful to check if a RFC1918 address is used in
>>> the call-id. I understand that it is not a thorough test for NAT,
>>> well, just like any other NAT test.
>>> Can someone please comment if it is a good test?
1:40 p.m.
I don't understand in which cases you are not able to detect NAT? We have
stun-configured clients running behind symmetric NAT and so far I've seen
most clients either do NOT attemp to rewrite themselves or they do rewrite,
but nat_uac_test("16") will catch them as the rewritten port is different
from the source port.
Isn't LinkSys Linux-based?
Here is an example of a Grandstream phone with stun configured behind a
LinkSys box:
U 2004/12/03 09:41:15.181973 ua-nat-public-ip:56611 -> sipproxy-ip:5060
REGISTER sip:domain.com SIP/2.0.
Via: SIP/2.0/UDP ua-nat-public-ip:56780;branch=z9hG4bK2d165c4f868349ec.
From: "User" <sip:username@domain.com>;tag=691e12d47e72e340.
To: <sip:username@domani.com>.
Contact: <sip:username@ua-nat-public-ip:56780>.
Authorization: DIGEST username="username", realm="domaine.com",
algorithm=MD5, uri="sip:domain.com",
nonce="41b027d7a0c4022445733bb7bdcaec4b1067d88f",
response="66389c7998c7cd5f4aa11ef2d6b3ca07".
Call-ID: 123977cd4979a634(a)192.168.1.102.
Using nat_uac_test("19"), ser correctly registers ua-nat-public-ip:56611 as
location and marks it as behind nat. Of course, a test on call-id would
also find that it was behind nat, but the port would still have to found in
source port.
One thing though: For example Grandstream will use stun to keep nat open on
all but symmetric NAT. If incoming keepalives (from the SIP server) are
discarded, the NAT port assignment will time out. GS must be configured
with NAT Yes and empty STUN server and it will send keepalives to the SIP
server. I'm not sure why this is not done automatically when SNAT is
detected...
What do you say? Have you other experiences?
g-)
Richard wrote:
-----Original
Message-----
From: Greger V. Teigre [mailto:greger@teigre.com]
Sent: Thursday, December 02, 2004 10:45 PM
To: Richard; serusers(a)lists.iptel.org
Subject: Re: [Serusers] nat test based on rfc1918 address in call-id
field
Sorry. I was a bit quick there. Do you have any particular
UAs/scenarios in
mind where this test will be more appropriate than the existing?
g-)
Stun doesn't work well with linux firewall.
http://www.netfilter.org/documentation/conferences/nf-workshop-2004-summary.
html#AEN106
> Richard wrote:
>> ________________________________________
>> From: Greger V. Teigre [mailto:greger@teigre.com]
>> Sent: Thursday, December 02, 2004 9:00 PM
>> To: Richard; serusers(a)lists.iptel.org
>> Subject: Re: [Serusers] nat test based on rfc1918 address in call-id
>> field
>>
>>> If I understand you correctly, you are talking about test 16 found
>>> in nathelper cvs. You may want to have a look at that test first.
>>> You call nat_uac-test("19") to trigger the test.
>>> g-)
>>
>> eh. test 16 is different. it tests if the source port is different
>> from the port in Via.
>>
>> The proposed test checks the private ip in Call-ID field.
>>
>>>> Hi,
>>>> I am thinking about having more NAT test on a sip packet. Just
>>>> want to find out if it is useful.
>>>> I run into some situations that some 'smart' UAs try to detect
its
>>>> external IP and put the external IP address into the sip packet.
>>>> Depending on the network and NAT firewall setup, it may or may not
>>>> set the right external IP and port in the packet. If it is not,
>>>> but pretends to be on the public internet, then there is most
>>>> likely a one-way voice or no voice issue. I'd like to be able to
>>>> detect and force it to use a nat proxy. By checking these
>>>> packets, I found that the only trace is the private IP address in
>>>> the call-id header field. It will be useful to check if a RFC1918
>>>> address is used in the call-id. I understand that it is not a
>>>> thorough test for NAT, well, just like any other NAT test.
>>>> Can someone please comment if it is a good test?
4 Dec
4 Dec
12:31 a.m.
I don't understand in which cases you are not able
to detect NAT? We have
stun-configured clients running behind symmetric NAT and so far I've seen
most clients either do NOT attemp to rewrite themselves or they do
rewrite,
but nat_uac_test("16") will catch them as
the rewritten port is different
from the source port.
The problem is that linux/netfilter uses port overload. It tries to reserve
the source port number whenever possible. So if an internal packet has
source 5060, it tries to keep use 5060 and only changes the source ip from
private to public. It only changes the source port if
protocol/src-ip/src-port/dest-ip/dest-port is not unique. For example, if
two phones go to different outside addresses, both will show up 5060 as the
source port. However if both go to the same address, the first one use 5060,
the second one has to change to make it unique.
For example, in the following packet, you only trace of behind NAT is the
Call-ID header.
80.12.34.5:5060-><server>:5060
INVITE sip:5551212@test.org SIP/2.0
Via: SIP/2.0/UDP
80.12.34.5:5060;rport;branch=z9hG4bK8F3C30F6C252453BBA6E3F14DD775BA4
From: 2375900 <sip:2375900@test.org>;tag=3667353892
To: <sip:5551212@test.org>
Contact: <sip:2375900@80.12.34.5:5060>
Call-ID: 1B8E0416-C131-4F66-A7D9-C48614E23CC6(a)192.168.5.110
CSeq: 43281 INVITE
Max-Forwards: 70
Content-Type: application/sdp
User-Agent: X-Lite release 1103a
Content-Length: 298
One thing though: For example Grandstream will use
stun to keep nat open
on
all but symmetric NAT. If incoming keepalives (from the SIP server) are
discarded, the NAT port assignment will time out. GS must be configured
with NAT Yes and empty STUN server and it will send keepalives to the SIP
server. I'm not sure why this is not done automatically when SNAT is
detected...
Incoming keepalives would not refresh the conntrack timer, only an
outbound
packet can. For this reason, we already disable the nat-ping in ser. We rely
on the UA to send out keepalive.
Thanks,
Richard
6 Dec
6 Dec
5:10 p.m.
On Dec 03, 2004 at 11:31, Richard <richard(a)o-matrix.org> wrote:
Yes, but if you use an outbound proxy, all the SIP traffic will go
always to the same address. So if the port is 5060 => it will work will
STUN. If the port is changed nat_uac_test("16") will catch it.
It gets uglier with media, but since you are not sending media from 2
different UAs to the same dst_addr/port it will work in most cases.
I don't
understand in which cases you are not able to detect NAT? We have
stun-configured clients running behind symmetric NAT and so far I've seen
most clients either do NOT attemp to rewrite themselves or they do
rewrite,
but nat_uac_test("16") will catch them
as the rewritten port is different
from the source port.
The problem is that linux/netfilter uses port overload. It tries to reserve
the source port number whenever possible. So if an internal packet has
source 5060, it tries to keep use 5060 and only changes the source ip from
private to public. It only changes the source port if
protocol/src-ip/src-port/dest-ip/dest-port is not unique. For example, if
two phones go to different outside addresses, both will show up 5060 as the
source port. However if both go to the same address, the first one use 5060,
the second one has to change to make it unique.
For example, in the following packet, you only trace of behind NAT is the
Call-ID header.
80.12.34.5:5060-><server>:5060
INVITE sip:5551212@test.org SIP/2.0
Via: SIP/2.0/UDP
80.12.34.5:5060;rport;branch=z9hG4bK8F3C30F6C252453BBA6E3F14DD775BA4
From: 2375900 <sip:2375900@test.org>;tag=3667353892
To: <sip:5551212@test.org>
Contact: <sip:2375900@80.12.34.5:5060>
Call-ID: 1B8E0416-C131-4F66-A7D9-C48614E23CC6(a)192.168.5.110
CSeq: 43281 INVITE
Max-Forwards: 70
Content-Type: application/sdp
User-Agent: X-Lite release 1103a
Content-Length: 298
Are you sure? The initial REGISTER is the oubound packet and the nat
pings are "replies" from the conntrack point of view. The corresponding
conntrack entry should be in the ESTABLISHED or ASSURED state, if the
timeouts are low enough (or the nat pings are sent often enough,
<<30s).
(see udp_packet() in ip_conntrack_proto_udp.c and ip_conntrack_in() in
ip_conntrack_core.c)
Andrei
One thing though: For example Grandstream will
use stun to keep nat open
on
all but symmetric NAT. If incoming keepalives (from the SIP server) are
discarded, the NAT port assignment will time out. GS must be configured
with NAT Yes and empty STUN server and it will send keepalives to the SIP
server. I'm not sure why this is not done automatically when SNAT is
detected...
Incoming keepalives would not refresh the conntrack timer, only an
outbound
packet can. For this reason, we already disable the nat-ping in ser. We rely
on the UA to send out keepalive.
8 Dec
8 Dec
3:24 p.m.
One thing though: For example Grandstream will use
stun to keep nat
open on
all but symmetric NAT. If incoming keepalives (from the SIP
server) are discarded, the NAT port assignment will time out. GS
must be configured with NAT Yes and empty STUN server and it will
send keepalives to the SIP server. I'm not sure why this is not
done automatically when SNAT is detected...
Incoming keepalives would not refresh
the conntrack timer, only an
outbound packet can. For this reason, we already disable the
nat-ping in ser. We rely on the UA to send out keepalive.
7276
days inactive
7282
days old
8 comments
3 participants
participants (3)
-
Andrei Pelinescu-Onciul -
Greger V. Teigre -
Richard