On Tue, 2004-05-18 at 14:21, alucard@xxxxxxxxx wrote: > > OK - it's good to simplify :-) > > You should not need to INPUT rule for 8080. > IÂtÂs commented, itÂs an old rule for something I used to have in that server > > > The delay in finding the default route is route's attempt at reverse > > name resolution. Use route -n instead. > > Indeed, this is what I get in server2 > > -------- > [root@linserv root]# route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo > 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 > -------- > > > Our next step is to trace. From what address are you attempting to > > telnet and where does that address live? > > IÂm using a completly different address to try to access the server from > the outside, to be more specific, I'm doing this at work and I'm using the > computers in my house to do this test and nothing happens. If I telnet > port 80 server2 directly from server1 I get this -to make sure it's > working-: > > -------- > root@mail:~# telnet 192.168.0.2 80 > Trying 192.168.0.2... > Connected to 192.168.0.2. > Escape character is '^]'. > ^] > telnet> > -------- <snip> Ok - so this is where the tracing comes in. I assume you are sending a packet from your home network to some public IP. Your ISP is then NATting this to 10.73.219.156. Using tcpdump or ethereal, can you see the packet arrive at 10.73.219.156? If so, can you see the packet leave 192.168.0.1?, If so, what are the source and destination sockets of the egressing packet? Do you see a reply packet? How is it addressed? If you do not see a packet exiting the gateway on the 192.168.0.1 interface, place log rules in the various points of your table to find out where the packet is dying. Good luck - John -- John A. Sullivan III Chief Technology Officer Nexus Management +1 207-985-7880 john.sullivan@xxxxxxxxxxxxx
