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
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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
________________________________________ 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. 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?
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@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?
-----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?
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?
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@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
On Dec 03, 2004 at 11:31, Richard richard@o-matrix.org wrote:
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.
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.
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@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.
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.
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)
Our experience is that for most symmetric NATs the SIP server NAT pings work ok, however, we have had problems with LinkSys where inbound pings every 20 s do not seem to be able to keep the connection open. g-)
-
Andrei Pelinescu-Onciul -
Greger V. Teigre -
Richard