[GnomeMeeting-list] Ekiga && usage of ports




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;

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;

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?

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

Thx

	matthias

-- 
Matthias Apitz
Manager Technical Support - OCLC PICA GmbH
Gruenwalder Weg 28g - 82041 Oberhaching - Germany
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <m apitz oclcpica org> - w http://www.oclcpica.org/ http://guru.UnixLand.de/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]