[Serusers] nat test based on rfc1918 address in call-id field

[Greger V. Teigre]

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 at domain.com>;tag=691e12d47e72e340.
To: <sip:username at domani.com>.
Contact: <sip:username at 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 at 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 at teigre.com]
>> Sent: Thursday, December 02, 2004 10:45 PM
>> To: Richard; serusers at 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 at teigre.com]
>>> Sent: Thursday, December 02, 2004 9:00 PM
>>> To: Richard; serusers at 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?