3 Dec
2004
3 Dec
'04
10:31 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.
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