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