3 Dec
2004
3 Dec
'04
5:40 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.
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?