Re: [GnomeMeeting-list] Gnomemeeting and firewall rules?

[Ivo Clarysse <soggie soti org>]

I've been trying the same thing, but for me it doesn't work completely
either.  (see interleaved comments below)

My status: with GnomeMeeting, I can transmit audio and video.
with ohPhone (using 'Fast Start' and H.245 tunneling), I can transmit and 
receive audio.

(Also see my Gnomemeeting notes on http://www.soti.org/~soggie/linux/gm/)

On 5 Mar 2002, Jeffrey Bell wrote:

> Hi,
> 
> I am running a debian box, kernel 2.4.17 with gm-0.12.2, I sit behind a
> debian firewall also running 2.4.17 using iptables. I have used the
> "patch-o-matic" to apply the cvs version of the newnat-0.7 patch to the
> firewall box. I recompile, reboot and have edited the firewall ruleset
> so upon a initialization the firewall loads the ip_conntrack_h323 and
> ip_nat_h323 modules. 
> 
> lsmod shows:
> 
> ip_conntrack_h323 2144 1 (autoclean)
> ip_nat_h323 2496 0 (unused)
> ip_conntrack 15244  10 (autoclean) [ip_nat_irc ip_conntrack_irc
> ip_nat_ftp ip_conntrack_ftp ip_conntrack_h323 ip_nat_h323 ipt_MASQUERADE
> iptable_nat ipt_state]
> 
> is the above ip_nat_h323 (unused) correct?

I see the same thing (unused), but NAT doesn't work for me.
> 
> <snip..snip> firewall script

In the firewall (not NAT) rules, you will need to check that you ALLOW
to following traffic:

OUTBOUND          TCP/389          ILS/LDAP
INBOUND+OUTBOUND  TCP/1720         H.323 Call Setup
INBOUND+OUTBOUND  UDP/1024-65535   RTCP / RTP streaming

If you don't use H.245 tunneling, you will also need to allow:

INBOUND+OUTBOUND TCP/1024-65535    H.245 media control
> 
(note: MS Netmeeting does not support H.245 tunneling; if you use 
NetMeeting on your Internal network, you will also need to allow
INBOUND+OUTBOUND traffic for TCP/1731 (MS Audio call control) and
TCP/1503 (T.120 imtc-mcs))

(note2: for GM <=> GM traffic, you don't need to open up ports UDP ports
1024-65535, 5000-5001 should suffice)


> /sbin/modprobe ip_tables
> /sbin/modprobe iptable_filter
> /sbin/modprobe ip_conntrack
> /sbin/modprobe ip_nat_h323
> /sbin/modprobe ip_conntrack_h323
> /sbin/modprobe ip_conntrack_ftp
> /sbin/modprobe ip_nat_ftp
> /sbin/modprobe ip_conntrack_irc ports=$IRCPORTS
> /sbin/modprobe ip_nat_irc ports=$IRCPORTS
> 
> I have found these two rules from the net somewhere reguarding firewall
> and gm,
> 
> $IPTABLES -A INPUT -p tcp -i $EXTIF  --dport 1720 -j ACCEPT
> $IPTABLES -t nat -I PREROUTING -i $EXTIF  -j DNAT -p tcp --dport 1720
> --to 192.168.1.9:1720
> 
> now the 192.168.1.9:1720 is my internal IP from the workstation I
> running gm on. By the way, this machine is a dhcp client which I have
> recentley disabled because of this rule, anyway around this --to
> 192.168.1.9.:1720?
> 
> Now my understanding is that if I enable h.245 tunneling from within gm
> that I don't have to worry about opening a couple ports or so. I know
> nm/gm has a few different ports to open in order to work and that the
> modules are supposed to assist in this reguard.
> 
> I have seen and received video and have been told that I have sent audio
> to someone who is runnning netmeeting on a windows box. I have yet to
> receive any audio from anyone. I run gnome with esd sound, I have to
> disable (kill) esd in order to use gm, I understand that I should use
> ALSA sound daemon instead of esd.

> 
> My question, is my firewall rules, shown above, with the h.245 tunneling
> enabled in gm, set up correctly to enable audio/video both way?
> 
> What is everybody else doing with reguards to gm behind a firewall?
> 
> 

While searching mailinglist archives, I did find this disturbing mail
on the netfilter-user list:

http://lists.samba.org/pipermail/netfilter/2002-February/019900.html
-----------------------------8<----------------8<-----------
Russell King - ARM Linux  linux arm linux org uk
Tue, 19 Feb 2002 15:52:01 +0000

[...] Secondly, if you
have "the wrong" IP address, the H.323 NAT module will totally mess up.
I have a violent disagreement with the H.323 NAT module to the extent
that I'd rather not use it, but re-number my network to eliminate the
NAT.  The H.323 NAT module and the H.323 protocol creates too much of
a security risk IMHO.

Let me enlighten you to how the NAT module works.  It knows nothing about
the H.323 protocol.  Instead, it applies the brute-force approach, and
searches for 4 bytes that look like an IP address.  On finding this, they
change these bytes to be the new source or destination address.  They
also assume the next two bytes are a port number.
[...]
-----------------------------8<----------------8<-----------
(in response to someone using 192.168.1.0/24 for their internal network)

I am using 192.168.42.0/24, you are using 192.168.1.0/24 ; I've not yet
looked hard enough at ip_nat_h323 to verify this claim, but maybe
192.168.x.y addresses don't play well with ip_nat_h323 ?

When I'm looking at packet capture dumps, I see outbound packets being
sent to some UDP (5000-5004) port, but occasionally get ICMP errors back
from certain ports (say, 5001 and 5003, but not 5000 and 5002) - it seems 
like occasionally the NAT module does a wrong translation.

If other people are using ip_nat_h323 successfully with GM, could you 
report:

  - which kernel you're running on the firewall
  - which newnat patch 
  - which internal network address range you use

?

Ivo. 

-- 
Ivo Clarysse               PGP key: DF533D7C           <soggie soti org>

H.R. Leuven 107057
BTW: BE 708.837.396
Rek: 735-0029047-32                         http://www.soti.org/~soggie/