On Sat, 19 Oct 2002, Randy Clarksean wrote:
> I have had some very odd problems with using NetMeeting through my firewall.
Ooooh boy.
> NetMeeting is on a Win2K system on an internal network. The server/firewall
> is on a RH7.2 system. I presently am using IPCHAINS for the firewall, but
> with the plans to convert to IPTABLES here shortly. As far as I can tell,
> there is presently no support for H.323 (netmeeting and other packages) for
> IPTABLES, but I could be wrong about that.
Yeah, you'll need iptables for this. RH7.2 has ipchains support, but it
doesn't come with ipmasqadm, which is needed for port-forwarding with
ipchains. (Something I wasn't especially happy to discover when I
switched my firewall to 7.2 -- oops.)
> Temporarily, I turned off the firewall and had the masquerading turned on.
> I also told the firewall software to let anything through that came from the
> IP address I was making the call to. So, I had hoped that it would work
> that way until I could work through the iptables issues.
"Let anything through." Hmm. The problem here is that the firewall
(probably) doesn't know that the packets coming in on its external
interface need to be redirected to the Win2K box. To let the firewall
know this, you need to forward some ports from the external interface of
your firewall to the Win2K machine.
> But ... it only partially worked. The people on the other end could see and
> hear me fine. I could not hear nor see them, but the chat window would come
> open, whiteboard was available, and they could share their desktop and I
> could see it. I find it very odd that part of the signals would make it
> through, while the rest were either blocked or did not make it in. I
> checked the message log for the system and I did not see any dropped packets
> from that IP address. It is my understanding that H.323 works on the
> premise of randomly selecting a port number to spawn a connection for a
> particular feature (I could be completely wrong on this .. but this is what
> I believe I read some place on the web).
I had to research this a few months ago, because a friend of mine needed
NetMeeting to work behind a firewall I installed. From what I recall,
your summary of how H.323 works is correct.
You'll need to forward some ports using iptables. Here're the ones I
have:
tcp: 389, 522, 1503, 1720, 1731
udp: 1024-65535
The port H.323 randomly selects is UDP. Yes, I realize allowing all of
those ports is a potential gaping security hole, which is why we filter
carefully.
Here's an example iptables script:
--- snip ---
#!/bin/bash
# eth0 is external, eth1 is internal
IPT=/sbin/iptables
WIN=192.168.1.200
REMOTE=1.2.3.4/255.255.255.255
# masquerade traffic going out
$IPT -t nat -A POSTROUTING -o eth0 -j MASQUERADE
$IPT -A FORWARD -i eth1 -o eth0 -s 192.168.1.0/255.255.255.0 -j ACCEPT
# pass the packets from the external interface to the win2k box
$IPT -A PREROUTING -t nat -i eth0 -p tcp --dport 389 -j DNAT --to $WIN
$IPT -A PREROUTING -t nat -i eth0 -p tcp --dport 522 -j DNAT --to $WIN
$IPT -A PREROUTING -t nat -i eth0 -p tcp --dport 1503 -j DNAT --to $WIN
$IPT -A PREROUTING -t nat -i eth0 -p tcp --dport 1720 -j DNAT --to $WIN
$IPT -A PREROUTING -t nat -i eth0 -p tcp --dport 1731 -j DNAT --to $WIN
$IPT -A PREROUTING -t nat -i eth0 -p udp --dport 1024: -j DNAT --to $WIN
# only allow packets on those ports to the win2k box from the remote ip
$IPT -A FORWARD -i eth0 -o eth1 -p tcp -s $REMOTE\
-d ${WIN}/255.255.255.255 --dport 389 -j ACCEPT
$IPT -A FORWARD -i eth0 -o eth1 -p tcp -s $REMOTE\
-d ${WIN}/255.255.255.255 --dport 522 -j ACCEPT
$IPT -A FORWARD -i eth0 -o eth1 -p tcp -s $REMOTE\
-d ${WIN}/255.255.255.255 --dport 1503 -j ACCEPT
$IPT -A FORWARD -i eth0 -o eth1 -p tcp -s $REMOTE\
-d ${WIN}/255.255.255.255 --dport 1720 -j ACCEPT
$IPT -A FORWARD -i eth0 -o eth1 -p tcp -s $REMOTE\
-d ${WIN}/255.255.255.255 --dport 1731 -j ACCEPT
$IPT -A FORWARD -i eth0 -o eth1 -p udp -s $REMOTE\
-d ${WIN}/255.255.255.255 --dport 1024: -j ACCEPT
# log and drop anything else
$IPT -A INPUT -i eth0 -m state --state NEW,INVALID\
-j LOG --log-level warning --log-prefix "INPUT (new/invalid): "
$IPT -A INPUT -i eth0 -m state --state NEW,INVALID\
-j DROP
$IPT -A FORWARD -i eth0 -m state --state NEW,INVALID\
-j LOG --log-level warning --log-prefix "FORWARD (new/invalid): "
$IPT -A FORWARD -i eth0 -m state --state NEW,INVALID\
-j DROP
--- snip ---
Ugh. It doesn't look like much, but it's a good starting point, I think.
> Any thoughts or comments? I need to get this video conferencing thing
> worked out fairly soon. I am having them check on their end to make sure
> they are sending video properly. I should know about that shortly as well.
I'd wager that they are.
Good luck with this. It's not exactly the simplest of tasks.
Jima