I've recently installed Gnutella P2P and am having problems related to my firewall. It's very difficult for Gnutella to connect to anyone, and the icon in the bottom left corner says it suspects I'm behind a firewall. To be honest I can't remember which firewall option I used when I was installing RH9.

I know from other threads that I have to change something to do with my iptables, but I know very little about these. The following is the output when I type "/sbin/iptables -L"

Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Lokkit-0-50-INPUT all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Lokkit-0-50-INPUT all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain RH-Lokkit-0-50-INPUT (2 references)
target prot opt source destination
ACCEPT udp -- NS1.es.net anywhere udp spt:ntp dpt:ntp
ACCEPT udp -- visserv1.slac.stanford.edu anywhere udp spt:ntp dpt:ntp
ACCEPT udp -- visserv2.slac.stanford.edu anywhere udp spt:ntp dpt:ntp
ACCEPT udp -- NS1.es.net anywhere udp spt:ntp dpt:ntp
ACCEPT udp -- visserv1.slac.stanford.edu anywhere udp spt:ntp dpt:ntp
ACCEPT udp -- visserv2.slac.stanford.edu anywhere udp spt:ntp dpt:ntp
ACCEPT udp -- dns1.lsanca.sbcglobal.net anywhere udp spt:domain dpts:1025:65535
ACCEPT udp -- dns1.snfcca.sbcglobal.net anywhere udp spt:domain dpts:1025:65535
ACCEPT udp -- NS1.es.net anywhere udp spt:domain dpts:1025:65535
ACCEPT udp -- visserv1.slac.stanford.edu anywhere udp spt:domain dpts:1025:65535
ACCEPT udp -- visserv2.slac.stanford.edu anywhere udp spt:domain dpts:1025:65535
ACCEPT udp -- anywhere anywhere udp spts:bootps:bootpc dpts:bootps:bootpc
ACCEPT udp -- anywhere anywhere udp spts:bootps:bootpc dpts:bootps:bootpc
ACCEPT all -- anywhere anywhere
REJECT tcp -- anywhere anywhere tcp dpts:0:1023 flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable
REJECT tcp -- anywhere anywhere tcp dpt:nfs flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable
REJECT udp -- anywhere anywhere udp dpts:0:1023 reject-with icmp-port-unreachable
REJECT udp -- anywhere anywhere udp dpt:nfs reject-with icmp-port-unreachable
REJECT tcp -- anywhere anywhere tcp dpts:x11:6009 flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable
REJECT tcp -- anywhere anywhere tcp dpt:xfs flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable

Can anyone help me keep Gnutella happy??

You likely need to open up the Gnutella ports. I'm not sure off-hand what they are, but I've seen 6346-6348, or 80, so check the README or installation documentation and see what are the default ports that Gnutella uses. In order to allow inbound connections add a rule to iptables like this:

iptables -I INPUT -p tcp --dport XX -j ACCEPT

Where XX is the default Gnutella port. Make sure to run that command as root. If that still doesn't work, post the contents of /etc/sysconfig/iptables after you've expunged any personally identifiable IP addresses.

Thanks Capt_Caveman, I'd almost given up on getting help!!

When I type the command you gave ("iptable -I.......") I just get the repsonse, "bash: iptables: command not found" I'm using RH9 -- maybe there's another command I need to use instead??

Can I alter the iptables file directly with emacs or something??

I know how to change the port used by Gnutella, so once I get this rule added to iptables, everything should work fine.

Once again, thanks for the help -- it's much appreciated by a Linux newbie!

When I type the command you gave ("iptable -I.......") I just get the repsonse, "bash: iptables: command not found" I'm using RH9 -- maybe there's another command I need to use instead??

You need to be root to run that command. Iptables should be in roots Path in RH9, but if you login as root (or use su -) and it still doesn't work, try running it using the full path:

/sbin/iptables -I INPUT -p tcp --dport XX -j ACCEPT


Can I alter the iptables file directly with emacs or something??

No absolutely not. The iptables file doesn'l like to be edited by hand. For this rule, it probably would still work, but editing the file can lead to iptables not working properly. Plus entering them from the command line allows you to spot syntax errors and any misspellings.

It didn't seem to work when I was root, but when I used the full path it accepted it just fine.

However,
Gnutella still thinks I'm working from behind a firewall (I know I am, but I thought that it wouldn't be able to see it now that I added the new rule), and is having difficulty connecting to people. Is there something I'm missing??

(I know I added the right port number, cos I used the one Gnutella says it's using.)

Thanks

I'm confused -- I used the command iptables -F, which should have disabled the firewall for the duration of the session (I think), however, Gnutella STILL won't connect. Every connection attempt results in failure -- most just say "Connection failed", while others complain about "HELLO reply error", etc.

Has anybody else had this problem?? I'm determined that Gnutella will NOT beat me!!!

Couple of things to try in order to troubleshoot this:

1. Turn off iptables and fire up your gnutella app. If it still can't connect, I would guess it's a problem with the application. Turn iptables back on once you're done testing.

Use:
service iptables stop
service iptables restart
to turn iptables off and back on.

If it gnutella does work, then we know it's the firewall, so:

2. As root, run the following command :

/sbin/iptables-save > /etc/sysconfig/iptables

and post the contents of that file. Make sure to scub any ip addresses which can identify you.

Thanks!

I turned off iptables like you said and started up gnutella. No joy It looks like the problem's with the application itself.

I've turned iptables back on now.

Is there any help you could give me with gnutella, or is this a problem that's gonna be unique to me???

Thanks for the help

I actually have a suspiction that the problem is with the firewall, just not your firewall. The stanford DNS servers that are being punched through the firewall are a likely hint. Try running this command as root:

traceroute -p 6346 www.yahoo.com

Before we mess with Gnutella, lets make sure that Stanford doesn't have their gateways blocking common p2p ports.

It can't find the command 'traceroute' unfortunately.

Also, at the moment I'm at home, and I'm not going through the Stanford system at all. The only firewall that should be affecting me is my own.

(I take it I should have hidden some of the lines I showed in my first post, so as not to identify myself!! I'll live and learn!!)

Sorry, I keep forgeting you don't have /sbin or /usr/sbin in root's path. Use the full path:

/usr/sbin/traceroute -p 6346 www.yahoo.com

Capt_Caveman,
The following is the output from the "traceroute" command. Does it tell you anything??

traceroute: Warning: www.yahoo.com has multiple addresses; using 66.218.70.49
traceroute to www.yahoo.akadns.net (66.218.70.49), 30 hops max, 38 byte packets
1 63-203-207-254.dsl.snfc21.pacbell.net (63.203.207.254) 8.970 ms 8.811 ms 9.129 ms
2 dist1-vlan50.snfc21.pbi.net (206.171.134.130) 8.490 ms 9.769 ms 9.895 ms
3 bb1-g8-1.snfc21.pbi.net (216.102.176.193) 47.482 ms bb1-g8-3-0.snfc21.pbi.net (209.232.130.82) 187.871 ms bb1-g1-3-0.snfc21.pbi.net (209.232.130.28) 192.172 ms
4 bb2-p4-0.snfcca.sbcglobal.net (151.164.190.190) 9.383 ms 9.879 ms 10.270 ms
5 ex1-p12-0.pxpaca.sbcglobal.net (216.102.176.234) 10.784 ms 10.955 ms 9.834 ms
6 ex2-p11-0.pxpaca.sbcglobal.net (64.161.1.50) 11.154 ms 11.534 ms 11.029 ms
7 151.164.89.170 (151.164.89.170) 10.785 ms 10.521 ms 11.159 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

Thanks

Looks like your packets are dying at one of your ISPs routers. That can mean one of two things: either your ISP has one of their routers configured to drop traceroute packets or they're blocking p2p ports. Run the same exact command but this time use a differernt port, say port 22. So run:

traceroute -p 22 www.yahoo.com

Once you see those stars start to appear, that means you packet got dropped. Just hit contol-c to stop it once you start to see them.

OK -- I used port 22 this time like you said, and the following happened. It looks like exactly the same thing to me.

traceroute: Warning: www.yahoo.com has multiple addresses; using 66.218.70.48
traceroute to www.yahoo.akadns.net (66.218.70.48), 30 hops max, 38 byte packets
1 63-203-207-254.dsl.snfc21.pacbell.net (63.203.207.254) 9.434 ms 9.008 ms 8.025 ms
2 dist1-vlan50.snfc21.pbi.net (206.171.134.130) 8.614 ms 9.724 ms 10.307 ms
3 bb1-g8-1.snfc21.pbi.net (216.102.176.193) 9.305 ms bb1-g8-3-0.snfc21.pbi.net (209.232.130.82) 13.305 ms bb1-g1-3-0.snfc21.pbi.net (209.232.130.28) 11.951 ms
4 bb2-p4-0.snfcca.sbcglobal.net (151.164.190.190) 9.270 ms 10.222 ms 9.255 ms
5 ex1-p12-0.pxpaca.sbcglobal.net (216.102.176.234) 9.818 ms 9.744 ms 10.283 ms
6 ex2-p11-0.pxpaca.sbcglobal.net (64.161.1.50) 11.339 ms 13.296 ms 11.894 ms
7 151.164.89.170 (151.164.89.170) 10.703 ms 14.965 ms 11.397 ms
8 * * *

Ok. Looks like they're blocking traceroute. That sucks, but oh well. Try using telnet to connect instead:

/usr/bin/telnet www.limewire.com 6346

I just tried it, and limewire does allow connections to 6346