According to FAQ #3 I tried to modrpobe the
H.323 connection tracking/NAT modules in kernel
2.6.20.
I can make a direct connection from H323 netmeeting
client at 87.219.113.116 (remote laptop with local ip
192.168.1.129) to another client at 85.48.224.145 (in
loc zone the client has IP address 10.215.144.98 and
is in the office LAN with a shorewall gateway).
However, I can''t stream video.
I noticed on the shorewall gateway that the h323
client in the loc zone is trying to send UDP packets
to the remote laptop but is using its local RFC1918 IP
address, not the public IP.
(...)
18:10:58.971782 IP 10.215.144.98.2334 >
192.168.1.129.49608: UDP, length 332
18:10:58.994780 IP 10.215.144.98.2336 >
192.168.1.129.49606: UDP, length 1401
18:10:59.003478 IP 10.215.144.98.2336 >
192.168.1.129.49606: UDP, length 235
18:10:59.011781 IP 10.215.144.98.2334 >
192.168.1.129.49608: UDP, length 332
18:10:59.034161 IP 10.215.144.98.2336 >
192.168.1.129.49606: UDP, length 1368
18:10:59.043573 IP 10.215.144.98.2336 >
192.168.1.129.49606: UDP, length 209
18:10:59.051800 IP 10.215.144.98.2334 >
192.168.1.129.49608: UDP, length 332
# lsmod | grep -i h323
nf_nat_h323 4962 0
nf_conntrack_h323 35016 1 nf_nat_h323
nf_nat 9868 14
ipt_SAME,ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,nf_nat_tftp,nf_nat_sip,nf_nat_pptp,nf_nat_proto_gre,nf_nat_irc,nf_nat_h323,nf_nat_ftp,nf_nat_amanda,nf_conntrack_netlink,iptable_nat
nf_conntrack 30456 29
ipt_MASQUERADE,ipt_CLUSTERIP,nf_nat_tftp,nf_nat_snmp_basic,nf_nat_sip,nf_nat_pptp,nf_nat_irc,nf_nat_h323,nf_nat_ftp,nf_nat_amanda,nf_conntrack_amanda,nf_conntrack_tftp,nf_conntrack_sip,nf_conntrack_proto_sctp,nf_conntrack_pptp,nf_conntrack_proto_gre,nf_conntrack_netlink,nf_conntrack_netbios_ns,nf_conntrack_irc,nf_conntrack_h323,nf_conntrack_ftp,xt_helper,xt_conntrack,xt_CONNMARK,xt_connmark,xt_state,iptable_nat,nf_nat,nf_conntrack_ipv4
ipv6 173176 17 nf_conntrack_h323
I also placed a shorewall dump at
http://85.48.227.158/shorewall/shorewall_dump.bz2
I would like to avoid using a gatekeeper like gnugk
because it seems that netmeeting in Win XP does not
register with a gatekeeper (it works fine with Win 2K
though).
Help appreciated,
Vieri
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
On Mon, 2007-12-03 at 10:12 -0800, Vieri Di Paola wrote:> I noticed on the shorewall gateway that the h323 > client in the loc zone is trying to send UDP packets > to the remote laptop but is using its local RFC1918 IP > address, not the public IP. > > (...) > 18:10:58.971782 IP 10.215.144.98.2334 > > 192.168.1.129.49608: UDP, length 332 > 18:10:58.994780 IP 10.215.144.98.2336 > > 192.168.1.129.49606: UDP, length 1401 > 18:10:59.003478 IP 10.215.144.98.2336 > > 192.168.1.129.49606: UDP, length 235 > 18:10:59.011781 IP 10.215.144.98.2334 > > 192.168.1.129.49608: UDP, length 332 > 18:10:59.034161 IP 10.215.144.98.2336 > > 192.168.1.129.49606: UDP, length 1368 > 18:10:59.043573 IP 10.215.144.98.2336 > > 192.168.1.129.49606: UDP, length 209 > 18:10:59.051800 IP 10.215.144.98.2334 > > 192.168.1.129.49608: UDP, length 332 >Which interface did you see that on? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
--- Tom Eastep <teastep@shorewall.net> wrote:> > On Mon, 2007-12-03 at 10:12 -0800, Vieri Di Paola > wrote: > > > I noticed on the shorewall gateway that the h323 > > client in the loc zone is trying to send UDP > packets > > to the remote laptop but is using its local > RFC1918 IP > > address, not the public IP. > > > > (...) > > 18:10:58.971782 IP 10.215.144.98.2334 > > > 192.168.1.129.49608: UDP, length 332 > > 18:10:58.994780 IP 10.215.144.98.2336 > > > 192.168.1.129.49606: UDP, length 1401 > > 18:10:59.003478 IP 10.215.144.98.2336 > > > 192.168.1.129.49606: UDP, length 235 > > 18:10:59.011781 IP 10.215.144.98.2334 > > > 192.168.1.129.49608: UDP, length 332 > > 18:10:59.034161 IP 10.215.144.98.2336 > > > 192.168.1.129.49606: UDP, length 1368 > > 18:10:59.043573 IP 10.215.144.98.2336 > > > 192.168.1.129.49606: UDP, length 209 > > 18:10:59.051800 IP 10.215.144.98.2334 > > > 192.168.1.129.49608: UDP, length 332 > > > > Which interface did you see that on?eth0 (loc zone). I should have been listening on eth7 I suppose (net4). Will try to redo the test. ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4