How to enable Iptables with Netmeeting

[cacosapo]

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?

[IKnowNot]

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.

[IKnowNot]

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.

[bAgZ]

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.

[bAgZ]

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.

[berkeley_147]

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

[bAgZ]

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

[IKnowNot]

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:

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:

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.

[cacosapo]

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.

[IKnowNot]

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!