it's probably some mac address issue or maybe clashing with iptables connection tracking. if you want two nics you must BOND them together, and add additional IP's to that single bond0.

You can have as many interfaces as you want you just have to decide which interface you want to have your default gateway on as you can only have one default. I'm not exactly sure why the routing works properly with 2 interfaces in the same subnet and a default gateway assigned to one interface and not when you have the same gateway twice, once on each interface. But if you watch the dump traffic on your cards ( i tried this because I was curious ) with the 2 gateways defined 1 card gets chosen to respond to all traffic. If only the gateway is only defined on one interface then the interface that received the packet is also the interface to return the packet. If you start talking interfaces in another subnet that's a whole different story and you need static routes setup to get the traffic to go back out the interface it came in.

1 members found this post helpful.

Ouch. I marked this as solved, and then i tried to log in, and I am locked out. It was working for almost 24 hours. and now its locked out.
Basically, I had set eth1 down., and restarted the services. It was working fine for almost 24 hours and now its down again.

so stop messing about with multiple interfaces for a start. TOTALLY remove eth1 form your system.

acid_kewpie: thats what i did. And, it was working for almost a day, and just when i thought everything is fine, it again locked me out. Dont know whats happening.

well so far i've seen no checking of any log files, nor of ssh client debug output, although tbh a timeout would suggest it's not going to show anything. you should determine if the traffic is actually hitting the machine in the first place.

I am not at work. So, i cannot get you the server logs. And as you have said, client log has nothing but the timeout message.

OpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xx.xx.xx.xx port 22.
debug1: connect to address xx.xx.xx.xx port 22: Operation timed out
ssh: connect to host xx.xx.xx.xx port 22: Operation timed out

And as i said, this time it was working for almost a day. Earlier never lasted more than 4 hours.

The point of demarcation you still would be if the traffic is reaching the box, NOT if you are establishing a connection. a time out only proves that traffic is not coming back to you from the remote server, NOT that the traffic doesn't hit that box in the first place... maybe the box has issues replying?

Is your public IP static?

Is there a way you can connect to a guest wireless network at the office? You can log into the server using the console or another machine and start a dump on eth0. Try connecting via the outside world using the guest network connection and see if your initial TCP SYN is received by the server.

tcpdump -i eth0 port ssh and host not <IP of the machine you are already SSH'd through>

If you leave out the "and host not <Connected IP>" you'll see way to much traffic as you'll end up in a recursive loop of the log output logging itself since it's sending over SSH to your machine.

Apparently, the eth1 has come back up and hence I was locked out.

Not sure how that happened. I had done ifconfig eth1 down, and also removed the eth1 entry in /etc/network/interfaces. Is there anything else i have to do to permanently disable eth1?

I will mark this issue as solved. Thank you all for your help.