This seems like a strange problem but I am a linux noob so it's highly possible I'm missing something simple.

Basically, when I log in as a standard user, I'm able to pull an IP and get on the internet fine.

In regards to SSH, however, I can only SSH to the machine from LOCALHOST (SSH'ing from the same machine to the same machine), not over the LAN or WAN from other computers.

Now, If I restart the network by using "WICD Network Manager" through KDE (or WICD-CLIENT from the command line) after logging in, the SSH problem will then be fixed and the world is safe once again.

I noticed that KDE is autostarting the WICD-CLIENT by using "/etc/xdg/autostart/wicd-tray.desktop". I tried moving that out temporarily and starting the WICD service by adding it to he startup services for rc4 but that didn't help. If KDE doesn't start WICD-CLIENT then the network doesn't work at all (completely dead).

Any thoughts? I'm guessing I need to run some other network scripts since I'm trying to get the network working outside of KDE? It seems like SSH should be working without having to log in to the desktop at all.

I also tried removing the startup file option for starting after the tray / panel (X-KDE-autostart-after=panel) - no luck there.

Which version of VL is this?have you installed any special firewall program or rules after the installation?

I'm running Vector Linux Light 6.0. Haven't had any other significant issues except sound and those are resolved.

I haven't set up any firewill stuff that I know of. I haven't seen the firewall script in init.d being called from any startup scripts in rc.d/rc# and I haven't seen it listed during the boot process. Is the firewall automatically run by VL somewhere else?

In rc.M, I saw rc.paranoid being called. I tried booting with the call to that script commented but I still have the same problem.

I just tested a similar scenario to see if I could recreate the trouble. I too had a non connectivity issue arise when trying to connect to VL Light using SSH from another system but as it turns out it was the firewall on the other system causing the problem. As soon as I dropped the firewall on the other system I was able to ssh and ping the VL light system. Perhaps you're running into a similar situation? Can you ping your VL light system from another LAN system?

I just tested a similar scenario to see if I could recreate the trouble. I too had a non connectivity issue arise when trying to connect to VL Light using SSH from another system but as it turns out it was the firewall on the other system causing the problem. As soon as I dropped the firewall on the other system I was able to ssh and ping the VL light system. Perhaps you're running into a similar situation? Can you ping your VL light system from another LAN system?

Well from what I could tell the problem seems to be confined to the Vector Light box, since I could ping the Vector Light box IP from the LAN and WAN but I couldn't SSH to it. The Vector Light box shares its IP with another laptop (windows) that doesn't have any network problems. These machines are both behind a router that's already doing port forwarding (already configured for SSH port forwards on Vector Light).

I was talking to a friend of mine that is pretty familiar with linux and he thinks its an initial firewall setup issue. He showed me the iptables list and thinks it might be initially "rejecting" everything except localhost on bootup - before I manually recreate the network with "wicd-client", which is when SSH magically starts accepting connections from the LAN and WAN.

The weird thing was that I tried commenting out the call to rc.paranoid and still had problems so I feel like there is another firewall hook somewhere - is rc.M the only script that runs rc.paranoid? I grep'ed my entire drive and didn't find anything else. Are there any other startup scripts that work with the firewall other than the standard "firewall" script? Just looking for other hooks to check.

I have to wait till I get home to check more into this and try some stuff out. If I reboot the system remotely I won't be able to get back in till I get home .

ssh 127.0.0.1The SSH will work with the localhost addresses. LAN or WAN addresses don't. This applies to me using other machines to SSH to this Vector Light box as well, but obviously its not the same machine in those cases, so localhost doesn't apply.

This entire problem goes away once I force a reconnect to the wired network through the desktop WICD Network Manager (or wicd-client).

Hope this helps. Does sound like a firewall issue to me the more I think about it. When I get home tonight I'm going to reboot and take a look at "iptables --list" and see how it's configured right after a boot. Hopefully it will say the policies are rejected so I can just figure out how to change the stored boot settings or find out what is setting them every time VL boots up.

Did some more testing tonight but didn't have much luck. In the end the problem still exists.

Some things I've tried:

Made rc.firewall, init.d/firewall, and rc.paranoid all non-runnable. I don't see anything firewall-based starting up.

Made my own startup script (rc4) to ensure iptable was granting full open access to INPUT, OUTPUT, and FORWARD

Something I did notice, however, was that when I first open up the WICD Network Manager after booting to the GUI (to restart the network), it says on the status bar on the bottom of the window that I'm NOT connected. It says this even though I am connected to the network and able to access the net. So my network is being created but WICD is not seeing it? Any thoughts?

I really think the iptables thing is too far. I have a network with 3 machines when 2 of them run vl and one runs windows. I never needed to Jack with iptables until I had to setup one of my Linux boxes as a router and file/print server. I don't see why you should need special rules in your iptables just for SSH access from within your LAN

Since you're using the wicd-client for configuring your network you need to make sure the wicd daemon is running upon boot so the client can establish the network connection without first requiring a physical login and manual initiation of the wicd-client. Enabling this via 'vasm/super/service/srvset/your_init_level' is probably the easiest way. I have a feeling the issues you're running into are related to the wicd daemon-to-client communication, but may very well be wrong.

Better yet, since you're VL system is in a permanent location with a static IP address you should set the system to configure the network without using wicd (daemon or client). You should just be able to add the following commands to the appropriate startup script:/sbin/ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up/sbin/route add default gw 192.168.1.1

Thanks for the replies and help - I didn't have much time to screw around with this stuff on the later part of the week but I'm going to try these suggestions out tonight. I'll post my results. Thanks again!