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

[Andrei Pelinescu-Onciul]

On Dec 03, 2004 at 11:31, Richard <richard at 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 at test.org SIP/2.0
> Via: SIP/2.0/UDP
> 80.12.34.5:5060;rport;branch=z9hG4bK8F3C30F6C252453BBA6E3F14DD775BA4
> From: 2375900 <sip:2375900 at test.org>;tag=3667353892
> To: <sip:5551212 at test.org>
> Contact: <sip:2375900 at 80.12.34.5:5060>
> Call-ID: 1B8E0416-C131-4F66-A7D9-C48614E23CC6 at 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