[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: forwarding gnutella ports with iptables

On Wed, 2003-01-01 at 11:02, Michael P. Soulier wrote:
> On 01/01/03 Alex Malinovich did speaketh:
> > Nope, this doesn't work either. After spending the last 24+ hours
> > messing around with this, I've learned at least one important thing. It
> > seems that all ports over 1024 aren't being forwarded. I set up oftpd on
> > my desktop system (behind the firewall) and set port 21 to be forwarded.
> > Everything works fine. I set oftpd to run on port 6346 and then set port
> > 6346 to be forwarded, and the request never makes it to my desktop
> > system. Now the only problem is figuring out why this is happening and
> > what to do about it. As always, any suggestions are greatly appreciated.
> > :)
>     I would be very surprised if this were true. I forward ports > 1024 all
> the time. You can confirm what is happening by sniffing on the NAT box with
> tcpdump. 
> tcpdump -i any tcp port 6346
>     That should show both interfaces, and all tcp traffic on port 6346. You
> should see the traffic coming in, and then being forwarded on. 

Ok, I finally got a chance to try this. I can't really make heads or
tails of the majority of this stuff, but as far as I can tell, each
message that comes in on the public interface, gets forwarded to private
interface and then the appropriate machine on the LAN. This is expected
since gnutella DOES work, just not really the way that I want it to. :)
The problem comes from the fact that gtk-gnutella still thinks that I'm
behind a firewall.

Actually, a great example of this NOT working is as follows:

-A PREROUTING -d -p tcp -m tcp --dport 6346 -j DNAT

as reported by iptables-save.

I'm running gtk-gnutella right now on my computer, My
roommate is also running gtk-gnutella right now on his computer, The above rule should send all traffic on 6346 to Yet, doing "tcpdump -i any tcp port 6346" shows plenty of
traffic headed for

Is there any way to track this down? Specifically, is there some way
that I can trace a single packet from the time it comes in to my NAT
box, as it passes through each of the filters, and is finally sent on to
the appropriate box? Preferably something that could show me the outcome
of each rule as it's encountered. Perhaps then I might be able to
actually track down the source of the problem? TIA.


Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: