Newbie Issues (networking w/ FreeBSD).. Solved

[Jon Adams]

Thanks for the response,
turns out Speakeasy (ISP) had... ahem.. reprovisioned my IP Address when I 
made some changes to my service.. figured this out by putting rl0 on another IP 
with the same settings.. its all fixed now.. and the IPFW issue is resolved 
(thanks to the person who posted the kld) (doh)... 

Still havent figured out how i was able to NMAP it from outside my net...  

oh well.. it works now..

Thanks
-- Jon


Quoting Kevin Stevens <freebsd at pursued-with.net>:

> 
> On Jun 14, 2004, at 05:08, Jon Adams wrote:
> 
> >  My network connectivity is ridiculously slow...  I had OpenSSH 
> > timeout set to
> > the default, 120 secs, and the messages file said the connections (on 
> > the same
> > 100MBPs hub mind you) were timing out before authentication 
> > (password).  I went
> > in and doubled the timeout, and after a long wait (I didnt check the 
> > time) I
> > could get a password prompt...  at first I thought this was just a SSH 
> > problem,
> > but it is the same if I use telnet (or any other network service).  I 
> > have
> > several devices on my Lan including 2 (eww) Windows XP laptops, and a 
> > PS2 and a
> > XP workstation.  I have 3 public IPs, (Speakeasy is the ISP) The 
> > laptops use a
> > LinkSys 54G Wireless Hub and one public IP (its plugged into a NetGear 
> > 4 port
> > hub), I split another IP with the Desktop and PS2, and the FreeBSD box 
> > will
> > have its own IP, of course the final port is the uplink.  There are 
> > absolutly
> > no connectivity problems with the other machines.  The FreeBSD box 
> > cannot
> > connect to the dns servers (on three different networks) or much of 
> > anything
> > else.
> >
> > Here is the really weird part, when I run an NMAP scan from inside the 
> > network
> > and one from outside the network, the box is reachable (NMAP can see 
> > the ports
> > and determine the OS), but nothing can connect to it (all connections 
> > time out).
> 
> If you can ping devices by ip address, you have basic connectivity.  
> Start with the local interface itself, then devices on the same 
> physical network, then devices on other subnets of the local LAN.  Any 
> of these local devices should respond in single-digit milliseconds, 
> with perhaps a drop of the first ping packet.  If you get "no route to 
> host" messages, or other total failure messages, check for 
> correct/consistent subnet masking on all devices involved, or potential 
> firewall blocking (if appropriate to configuration).  If you get poor 
> response (high dropped packet percentage, excessive delays), check for 
> port speed/duplex matching problems or bad cabling.
> 
> Assuming basic connectivity, many application timeout issues in Unix 
> systems result from either forward or reverse name resolution failure.  
> It can be frustrating to resolve, generally hard-coding the host and 
> FQDN entries in the local hosts file and with the hostname utility is a 
> good debugging step.
> 
> KeS
> 
>