GNOME.org
 

Re: [GnomeMeeting-list] Ekiga && usage of ports

Le jeudi 29 juin 2006 à 16:13 +0200, guru Sisis de a écrit :
> 
> In my company I've the following scenario:
> 
>  private IP address range             :          Internet
>  192.168.2.x                          :          (public IP address range)
>                        |              :
>                        |              :         cazador.sisis.de
>  +-------------+       |       +--------------+
>  | laptop1     | .3    |    .1 | firewall     | publicIP 193.31.11.193
>  | FreeBSD 6.0 |---------------| ipf / NAT    |------------>>
>  | Ekiga       |       |       |              |
>  +-------------+       |       +--------------+
>                  iwi0  |   eth0       :        eth1
>                        |
>                        |
>  +-------------+       |
>  | laptop2     | .4    |
>  | FreeBSD 6.1 |-------|
>  | Ekiga       |
>  +-------------+ iwi0
> 
> i.e.  the both laptops are behind a firewall with ipfilter and NAT;
> the ipfilter allows outgoing UDP above port > 1024, but incoming
> UDP is only allowed when for the connection first one outgoing pkg
> was registered by the firewall; this is the normal behaviour of ipfilter;
> 
> both Ekiga have been compiled from the same rources (2.0.2) and
> can register fine to the server ekiga.net using stun.ekiga.net also;
> ok, they can't be used at the same time because from the point of
> view of the ekiga.net server they come from the same publicIP using
> the same source ports; that's what I've learned from Damien (thx)
> and it is clear why;

If you can increase the UDP Binding time on the kernel, they will be
both reachable from the outside at the same time and be able to do calls
with people from the outside.

One can call the other (and vice-versa) but audio/video won't be
transmitted between the 2 internal machines.

> 
> interestingly there is a difference between the two Ekiga:
> 
> when I call from 'laptop2' the echo-room sip:500 ekiga net the
> traffic looks like this:
> 
> 15:03:27.606039 IP 193.31.11.193.5066 > 213.186.62.145.5060: UDP, length: 994
> 15:03:27.641615 IP 213.186.62.145.5060 > 193.31.11.193.5066: UDP, length: 718  
> 15:03:27.645378 IP 193.31.11.193.5066 > 213.186.62.145.5060: UDP, length: 456  
> 15:03:27.754619 IP 193.31.11.193.5066 > 213.186.62.145.5060: UDP, length: 1199
> 15:03:27.813838 IP 213.186.62.145.5060 > 193.31.11.193.5066: UDP, length: 588  
> 15:03:27.817774 IP 213.186.62.145.5060 > 193.31.11.193.5066: UDP, length: 879
> 15:03:27.825067 IP 193.31.11.193.5066 > 213.186.62.145.5060: UDP, length: 791 
> 15:03:29.815071 IP 213.186.62.145.14394 > 193.31.11.193.5026: UDP, length: 172
>                                           ^^^^^^^^^^^^^^^^^^^ of course blocked
> 15:03:29.844305 IP 213.186.62.145.14394 > 193.31.11.193.5026: UDP, length: 172
> 15:03:29.864153 IP 213.186.62.145.14394 > 193.31.11.193.5026: UDP, length: 172
> 15:03:29.884092 IP 213.186.62.145.14394 > 193.31.11.193.5026: UDP, length: 172
> 15:03:29.904118 IP 213.186.62.145.14394 > 193.31.11.193.5026: UDP, length: 172
> 15:03:29.924144 IP 213.186.62.145.14394 > 193.31.11.193.5026: UDP, length: 172
> 15:03:29.943855 IP 193.31.11.193.5026 > 213.186.62.145.14394: UDP, length: 172
>                    ^^^^^^^^^^^^^^^^^^ but this outgoing package open the fw.  
> 
> 15:03:29.944196 IP 213.186.62.145.14394 > 193.31.11.193.5026: UDP, length: 172
> 15:03:29.964196 IP 213.186.62.145.14394 > 193.31.11.193.5026: UDP, length: 172
> 15:03:29.974823 IP 193.31.11.193.5026 > 213.186.62.145.14394: UDP, length: 172
> 
> as you see the first incoming packages from
> 
> 	213.186.62.145.14394 > 193.31.11.193.5026
> 
> are blocked by the firewall, because no outbound traffic for this
> was seen before and later there is an outbound pkg and from now
> the traffic works fine in both directions; Ekiga plays the greeting
> of the echo-room;

Right.

> 
> when I call from 'laptop1' the echo-room sip:500 ekiga net the
> traffic looks like this:
> 
> 14:29:29.183089 IP 193.31.11.193.5067 > 213.186.62.145.5060: UDP, length: 998 
> 14:29:29.218499 IP 213.186.62.145.5060 > 193.31.11.193.5067: UDP, length: 722
> 14:29:29.223168 IP 193.31.11.193.5067 > 213.186.62.145.5060: UDP, length: 460
> 14:29:29.345525 IP 193.31.11.193.5067 > 213.186.62.145.5060: UDP, length: 1203
> 14:29:29.381244 IP 213.186.62.145.5060 > 193.31.11.193.5067: UDP, length: 592
> 14:29:29.385184 IP 213.186.62.145.5060 > 193.31.11.193.5067: UDP, length: 885
> 14:29:29.395124 IP 193.31.11.193.5067 > 213.186.62.145.5060: UDP, length: 795
> 14:29:30.169323 IP 193.31.11.193.5046 > 213.186.62.145.15416: UDP, length: 1024
> 14:29:30.170540 IP 193.31.11.193.5046 > 213.186.62.145.15416: UDP, length: 1000
> 14:29:30.171389 IP 193.31.11.193.5046 > 213.186.62.145.15416: UDP, length: 971
> 14:29:30.172398 IP 193.31.11.193.5046 > 213.186.62.145.15416: UDP, length: 1007
> 14:29:30.173284 IP 193.31.11.193.5046 > 213.186.62.145.15416: UDP, length: 1019
> 14:29:30.173737 IP 193.31.11.193.5046 > 213.186.62.145.15416: UDP, length: 497
> 14:29:31.400677 IP 213.186.62.145.13548 > 193.31.11.193.5042: UDP, length: 172
>                                           ^^^^^^^^^^^^^^^^^^ of course blocked
> 14:29:31.430264 IP 213.186.62.145.13548 > 193.31.11.193.5042: UDP, length: 172
> 14:29:31.450201 IP 213.186.62.145.13548 > 193.31.11.193.5042: UDP, length: 172
> 14:29:31.470139 IP 213.186.62.145.13548 > 193.31.11.193.5042: UDP, length: 172
> 14:29:31.490164 IP 213.186.62.145.13548 > 193.31.11.193.5042: UDP, length: 172
> 14:29:31.510191 IP 213.186.62.145.13548 > 193.31.11.193.5042: UDP, length: 172
> 	...
> 
> ie. there is never ever an outbound package for the connection
> 
> 	213.186.62.145.13548 > 193.31.11.193.5042
> 
> and nothing can be pass in; consecuently no greeting is not played
> and nothing is working;
> 
> Questions:
> 
> 1. Why is the *server* using in the first connection 5026 as target
>    port and in the second example 5042? Is this somehow proposed
>    in the SIP exchange by the client?

Probably yes. It must be the result of a SIP negotiation using STUN.

> 
> 2. Why the Ekiga in the first example is sending UDP out and in the
>    second nothing is sent?
> 

It is sending RTP :
14:29:30.173737 IP 193.31.11.193.5046 > 213.186.62.145.15416: UDP,
length: 497

However :
14:29:31.430264 IP 213.186.62.145.13548 > 193.31.11.193.5042: UDP,
length: 172

Again, my conclusion is the same. The IPFilter NAT is messing things up
and doesn't seem to work with STUN. I guess that a careful examination
of the -d 4 output would help you.

The solution is to install sipproxd on the IPFilter router and use it as
outbound proxy in Ekiga.
-- 
 _      Damien Sandras
(o-     
//\     Ekiga Softphone: http://www.ekiga.org/
v_/_    FOSDEM 2006    : http://www.fosdem.org/
        SIP Phone      : sip:dsandras ekiga net
                         sip:600000 ekiga net
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]