On the server, run the ssh daemon on a different port with debugging turned on, and connect to it with the ssh client with the verbose flag. As in:
sshd -ddd -p 2222
And on the client (server1) try:
ssh -vvv -p 2222 server2
That's the typical first step unless you have some other data to start with. If that doesn't help (doesn't give further clues), I would try strace or ltrace against the normal sshd on server2.
Good luck.
The general procedure here should be to eliminate classes of problems to narrow things down, as with any troubleshooting. Initially, I thought your question was specific to ssh (specifically OpenSSH on Linux), and checking the debugging messages is a valid first step if you have an ssh problem between 2 hosts.
However, you mentioned that other applications between the two boxes aren't working, which means that it's not an application-specific problem. OpenSSH debugging might help, but it's going to be worthwhile to assume there is something that's common to all these protocols (the network) that has a problem. Furthermore, you say that a third server can reach server2... so that eliminates a huge number of potential problems.
My best guess at the moment is, based on the connection timing out and the other info, that you have an iptables problem on either the server or client, something set to DROP packets outgoing from the client or incoming on the server, but only from that box and not others. I'm hobbled by my ignorance of APF on this point, I just use stock iptables.
If iptables is completely disabled (with the chain policies reset to ACCEPT), then you have to assume it's a more generic network problem. I asked about the netmask because I was thinking about similar problems I have seen in the distant past, where boxes on different subnets could talk, but ones on the same subnet didn't work. If "server3" is on a different network and can still reach server1 and server2, then it's not a routing issue.
Whatever the answer is here, I'm curious.