How to enable Iptables with Netmeeting

Hi all,

I''m using Fedora Core 3 firewall ( NAT ).I have faced netmeeting probelm .. External to Internal. I can call Internal MS XP to External MS XP. ... How to configure .. external to local xp.
OUTSIDE IP: 10.242.194.20 xp PC

FC 3 NAT = ext ip 10.242.194.19
NAT = int ip 10.10.10.10

inter network ip 10.10.10.9

I want to get netmeeting with 10.242.194.20 to 10.10.10.9

I've got below info .. but this error
http://www.cryogenic.net/nmproxy.html
mproxy#./nmproxy_install
This software may only be used by a non-profit entiity.
Will this software only be used by a non-profit entiry? ( Y or N ) [N] y
cp: cannot stat 'nmproxy.Linux' : No such file or directory
anyone can help ?

Thanks in advance

Greets Berkely,


Can you explain more specifically what you are trying to do? (the reason for the meeting and the IP's) The "Non-profit" message may be serial key issue.

Did you purchase the program? Or is it cracked?



:)

Just i want to get netmeeting external PC to NAT firewall internal PC.
it is completely free not for commercial use .

Did you build it from the source you downloaded before trying to install it?


make -f Makefile.Linux

yap,

I tried that ,

make -f Makefile.Linux
cc -g -DDEBUG -wall -c h225.c
make: *** [h225.0] Error 127

.. got this error.
any idea ?

Quote:

---

make -f Makefile.Linux
cc -g -DDEBUG -wall -c h225.c
make: *** [h225.0] Error 127

---

AFAIK, it could be a path problem, lib problem, etc.

Make sure your system is up-to date and you have all the necessary gcc files loaded
For this box ( FedoraCore 3 ),
$ rpm -qa |grep gcc
gcc-objc-3.4.4-2.fc3
gcc-3.4.4-2.fc3
gcc-c++-3.4.4-2.fc3
gcc-java-3.4.4-2.fc3
libgcc-3.4.4-2.fc3
gcc-g77-3.4.4-2.fc3

Then delete the directory and rebuild it with
tar -xzvf nmproxy_src.tar.gz

change to that directory and try again.

make -f Makefile.Linux

If that doesn't work, ( I don't know what permissions or path you gave the user you are utilizing ) try
su -
that will give you root privileges and include root's path. Now change back to the nmproxy directory and try again.

If you still get the same problem, try

make -d -f Makefile.Linux > problem.txt

review the file problem.txt to see if you can find where it is failing, if not, attach it here, maybe someone can help further.

you dont need a proxy to run netmeeting thru a linux box.
You just need a good iptables config.
You need to add nat rules to config, such as this:

Code:

---

iptables -A PREROUTING -t nat -p tcp -d your.public.ip --dport 1720 -j DNAT --to your.internal.ip:1720
iptables -A FORWARD -p tcp -d your.internal.ip --dport 1720 -o your.internal.adapter -j ACCEPT

---

Another way is install conntracks for h.323. I think they are ip_conntrack_h323 and ip_nat_h323, but i've never used those.
There is some documentation on www.netfilter.org about them.

Thanks
IKnowNot and cacosapo,

When i type this line,
iptables -A FORWARD -p tcp -d your.internal.ip --dport 1720 -o your.internal.adapter -j ACCEPT
error:=>> #iptables: no chain/target/match by this name :p
How sould i do next step ?

Thanks
IKnowNot and cacosapo,

When i type this line,
iptables -A FORWARD -p tcp -d your.internal.ip --dport 1720 -o your.internal.adapter -j ACCEPT
error:=>> #iptables: no chain/target/match by this name :p
How sould i do next step ?

err...
i hope that i you had replaced "your.internal.ip" and "your.internal.adapter" by your ip address and your linux ethernet adapter name :)
Otherwise i dont think you have enough basic knowledge to deal with linux. Perhaps a friend of your can help you on this matter?

err...
i hope that i you had replaced "your.internal.ip" and "your.internal.adapter" by your ip address and your linux ethernet adapter name :)
Otherwise i dont think you have enough basic knowledge to deal with linux. Perhaps a friend of your can help you on this matter?

my guess is he did, iptables would have given a different error had he not.

Since you can not delete ( so they say ) the three default chains in the filter
table ( INPUT, OUTPUT, and FORWARD ) my guess is maybe he either
misspelled FORWARD or did not capitalize it.

my guess is he did, iptables would have given a different error had he not.

Since you can not delete ( so they say ) the three default chains in the filter
table ( INPUT, OUTPUT, and FORWARD ) my guess is maybe he either
misspelled FORWARD or did not capitalize it.

Hi i configured mine like this:

iptables -I PREROUTING -t nat -p tcp --dport 1720 -j REDIRECT
iptables -I INPUT -p tcp --dport 1720 -j ACCEPT
iptables -I INPUT -p tcp --dport 10200:10209 -j ACCEPT
iptables -I INPUT -p udp --dport 10200:10259 -j ACCEPT
iptables -I INPUT -p tcp ! --syn -j ACCEPT

Hope it helps.

Hi i configured mine like this:

iptables -I PREROUTING -t nat -p tcp --dport 1720 -j REDIRECT
iptables -I INPUT -p tcp --dport 1720 -j ACCEPT
iptables -I INPUT -p tcp --dport 10200:10209 -j ACCEPT
iptables -I INPUT -p udp --dport 10200:10259 -j ACCEPT
iptables -I INPUT -p tcp ! --syn -j ACCEPT

Hope it helps.

Thanks for all, This is the simplest way of my iptables, But now I can't also get internet windows xp to external windows xp.After i run iptables ,Save like that # service iptables save
I have done all of your ieda, still can't get netmeeting ...... >>

# Generated by iptables-save v1.2.11 on Tue Jan 17 13:56:40 2006
*filter
:INPUT ACCEPT [4725:2869978]
:FORWARD ACCEPT [127:39118]
:OUTPUT ACCEPT [2641:2333465]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -j ACCEPT
-A INPUT -p udp -m udp --dport 10200:10209 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10200:10209 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1720 -j ACCEPT
COMMIT
# Completed on Tue Jan 17 13:56:40 2006
# Generated by iptables-save v1.2.11 on Tue Jan 17 13:56:40 2006
*nat
:PREROUTING ACCEPT [972:121081]
:POSTROUTING ACCEPT [231:26401]
:OUTPUT ACCEPT [231:26401]
-A PREROUTING -p tcp -m tcp --dport 1720 -j REDIRECT
-A POSTROUTING -s 10.0.0.0/255.0.0.0 -o eth0 -j MASQUERADE
COMMIT
# Completed on Tue Jan 17 13:56:40 2006

I made a call from external xp to Fedora Core 3's external ip .. to forward or redirect .. ... internal windows xp.
thanks all
Berkeley

Looks like you are missing nat rules. Try installing nmproxy first. The proxy understands the protocols used by NetMeeting. Then also try adding these rules in for the firewall:

iptables -I PREROUTING -t nat -p tcp --dport 10200:10209 -d $FIREWALL -j DNAT --to-destination $PROXY
iptables -I PREROUTING -t nat -p udp --dport 10200:10259 -d $FIREWALL -j DNAT --to-destination $PROXY
iptables -I PREROUTING -t nat -p tcp --dport 1720 ! -s $PROXY -j DNAT --to-destination $PROXY

I think it might be time to step back and look at what is going on.

What bAgZ wrote is directly out of the homepage of nmproxy ( which I haven't used, BTW. ) It is meant for the nmproxy, where the proxy is installed on the firewall box ( thus the INPUT statements. It can be used on another box, and the firewall rules would have to be adjusted accordingly.)

So, bAgZ , did you set up nmproxy ( or NetMeeting proxy as it is referred to there ) and test it? What did you think of it?

My initial responses were not to judge the software, but to answer questions asked about installing it. I have only used the
h323-conntrack-nat - h323 connection tracking and NAT helper which is what I believe cacosapo referred to. Based on the discussion, I thought it might be a little too involved in that one would have to rebuild the kernel and patch Netfilter to use.

I was also curious about this proxy because of security concerns with the h323 protocol in the past. Although I have found nothing specific concerning Netfilter, one must be very careful when setting it up a protocol such as this.
For instance:

Quote:

---

iptables -I INPUT -p tcp ! --syn -j ACCEPT

---

Is there anyone else besides me who has a problem with this????

Perhaps something like
iptables -A INPUT -p all -i your.external.adapter -m state --state ESTABLISHED,RELATED -j ACCEPT
might be a better alternative? ( why not use what Netfilter has to offer? )


Which leads me to these:

Quote:

---

iptables -I INPUT -p tcp --dport 1720 -j ACCEPT
iptables -I INPUT -p tcp --dport 10200:10209 -j ACCEPT
iptables -I INPUT -p udp --dport 10200:10259 -j ACCEPT

---

The first is obvious, it opens the port for nmproxy, which is listening on that port when it is running ( so, better make sure it is running ).

But nmproxy does not appear to be bound to those other ports; 10200 thru 10209 TCP and 10200 thru 10259 for UDP. I'm guessing they are opened for the other protocols to use once a netmeeting connection is made, otherwise they are left hanging in the breeze?


That concerns me, and is what the h323-conntrack-nat - h323 connection tracking and NAT helper was written to address.



BTW, cacosapo, what other firewall rules did you use to help establish the helpers to the h323 protocol, while maintaining the integrity of your firewall?

What berkeley_147 was initially looking for was a way to allow an external NetMeeting request to connect to an internal box. If you have only one NetMeetng client on your network nmproxy might suit your needs, but so would a NAT and h323-conntrack-nat - h323 connection tracking and NAT helper .
But if you have more then one, what you really need is a gatekeeper to manage those connections.
( see IEC's H.323 tutorial For more information. )

You might try GNU Gatekeeper for more info.

Quote:

---

BTW, cacosapo, what other firewall rules did you use to help establish the helpers to the h323 protocol, while maintaining the integrity of your firewall?

---

I've never used those modules. However, as far i understand, when you load those conntracks, you will be able to use connection tracking feature, such as --state subkeywords.
However, i still cant understand how the conntrack can help us when receiving external calls. I have same doubt with p2p conntracks.
For example, on FTP conntrack can "see" the handshaking on control session and understand that an incoming FTP-DATA connection (active FTP) is RELATED to that FTP control session.
But in a h323 session (or a p2p session) you are listed on a external directory and someone call you without any previously outbound connection . (is that right?)

So the only way that i can see to allow incoming calls is to insert a rule in FORWARD chain (and the associate NAT rule) , allowing that especific listening port to receive NEW connections. (same idea on p2p networks). So, you will appear on Internet listening to that port. I dont think that will "open a breach" on your network security. Only if your software has a vulnerability....but its not our discussion here.

Ok berkeley_147 , two posts were made while I was writing my last post, another while writing this


A better post to describe your firewall rules ( maybe as a .txt attachment ) would be
iptables --list -n --line-numbers > firewall_rules.txt
Then read the file created ( firewall_rules.txt )
Do this after a restart. This should list all the current rules.

As far as NATing of the ports tcp 10200:10209, udp 10200:10259 as bAgZ suggested, it will depend on where the proxy was installed. If it was installed on the firewall box itself, they may not have to be NATed at all ( including tcp 1720: I don't understand why they included a REDIRECT target in the suggested rule set, this may be due to a lack of understanding by the author's part, or mine ). The proxy should do that for you.

Let me explain this a little. If you are using the nmproxy on your firewall box itself, the rules for it will be INPUT rules for all devices. The proxy should manage all forwarding of packets ( should . )
But you have to remember, the firewall box will need rules ( OUTPUT ) to allow it to connect to the internal box that the proxy is trying to connect to ( your internal XP box ) as well as rules for the internal XP box to communicate with the proxy ( the INPUT rules listed should do this as well ), then allow the proxy to let the connection out to the box attempting to connect to the Netmeeting session ( OUTPUT rules again. )

Perhaps, if the proxy is set up on the firewall box, ( and this is not based on nmproxy but my understanding of Netfilter,) you should:


delete the rule
iptables -I INPUT -p tcp ! --syn -j ACCEPT
and replace it with
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Then, set up output rules, such as:
iptables -A OUTPUT -tcp --dport 1720 -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Again, make sure the proxy is running! I can not verify the security of the nmproxy software, but if it is running port 1720 should be bound to it. If not, you opened a hole at that port.

Please read my previous post as well. If you have further problems, perhaps you should enable logging of all packets then review your logs to see where it is failing. I will try to help as time allows.

Anyone, feel free to join in here!

cacosapo , in response to your last post, if no one else answers, and you still have these questions ( probably best addressed on the Netfilter mailing lists ) I will attempt to answer them at a later time: remind me. I am too drunk and too tired now, and am getting ragged on by my wife to go to bed! :confused:

Iknownot: just trying to add something to your post, the REDIRECT target is correct.
Redirect is commonly used on transparent proxy. It redirects routed frames to the firewall machine. If i understand correctly, that proxy is running under same linux as iptables and there is no proxy configuration on netmeeting (if there is, i think that is not a "transparent proxy"). If you dont specify any subkeyword on REDIRECT, the port wont be changed (that is the desired behavior).
I still think that a proxy inst necessary on that configuration and just make the thing worst. However im too lazzy to write an entire iptables configuration here :)

This is how i did it. I installed nmproxy on fedora without any problems. Then enabled IP forwarding.

Only had one error cp: cannot stat 'nmproxy.Linux' : No such file or directory
but that was easly fixed by doing this:
cp Makefile.Linux Makefile
make
After that just installed it as usual.

I then opened port 1720 on my firewall.
Net Meeting opens random ports for video and audio so it wont work over a firewall without
some help from nmproxy.

I ran this next:
iptables -A PREROUTING -t nat -p TCP -d $ip_of_your_firewall
--dport 1720 -j DNAT --to $ip_of netmeeting_box:1720

These open needed ports for nmproxy. You need these and you'll find it in nmproxy.conf file:
iptables -I INPUT -p tcp --dport 1720 -j ACCEPT
iptables -I INPUT -p tcp --dport 10200:10209 -j ACCEPT
iptables -I INPUT -p udp --dport 10200:10259 -j ACCEPT

My proxy and my firewall are on different machines. So i copied these specific rules of the web from http://www.cryogenic.net/nmproxy.html#Firewall:

iptables -I PREROUTING -t nat -p tcp --dport 10200:10209 -d $FIREWALL -j DNAT --to-destination $PROXY
iptables -I PREROUTING -t nat -p udp --dport 10200:10259 -d $FIREWALL -j DNAT --to-destination $PROXY
iptables -I PREROUTING -t nat -p tcp --dport 1720 ! -s $PROXY -j DNAT --to-destination $PROXY

In nmproxy.conf i only changed the follwoing line
# default_forward=4.5.6.7
to default_forward=192.168.0.37

Its working fine and it was easy to setup. I think its excellent and easy to use. The only bad thing about nmproxy is that it's not free for commerical use.

Quote:

---

Iknownot: just trying to add something to your post, the REDIRECT target is correct.

---

Yes, I believe you are correct. Apparently it is used to intercept all requests to the outside, from inside. I was thinking the other way, since I am used to seeing this with changing the ports from within.

Quote:

---

I still think that a proxy inst necessary on that configuration and just make the thing worst. However im too lazzy to write an entire iptables configuration here

---

Remember, one has to consider the firewall used. If default policies are set to deny ( as they should, and not necessarily the default ) it may be more difficult to get this thing working. And the helpers ( sound, etc. ) won't be forwarded with just a NAT of port 1720. ( Again, haven't tried this in years ... but when I did it wouldn't work, thus the necessity of the h323-conntrack-nat - h323 connection tracking and NAT helper .)

As bAgZ confirmed, this is a much simpler way to set something like this up instead of patching Netfilter and the kernel, but I am still concerned with those rules.