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 12.159.251.11 -p tcp -m tcp --dport 6346 -j DNAT --to-destination 192.168.0.8:6346 as reported by iptables-save. I'm running gtk-gnutella right now on my computer, 192.168.0.8. My roommate is also running gtk-gnutella right now on his computer, 192.168.0.9. The above rule should send all traffic on 6346 to 192.168.0.8. Yet, doing "tcpdump -i any tcp port 6346" shows plenty of traffic headed for 192.168.0.9. 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. -Alex
Attachment:
signature.asc
Description: This is a digitally signed message part