ssh timed out

[alleb57]

Hi)

I have a problem with ssh. Situation is: I have a local network consisting of a router asus wl700ge and 2 computers connected to it, one of them running windows xp and another (very old one) - FreeBSD 8.2. Also I have some virtual machines on the xp machine, one of them running FreeBSD 8.2, with network adapter bridged to the local network.

FreeBSD on the virtual machine is configured just like FreeBSD on the old computer. I have a dynamic IP on the router and it is connected to the dyndns account, say, myaccount.dyndns.org. Router uses dchp and assigns local address, say, 192.168.0.2 to the old comp, and 192.168.0.3 to the FreeBSD virtual machine.

I have sshd running on both FreeBSD, both with the default configuration file except that ports are, say, 1 for the old comp and 2 for the virtual FreeBSD machine. Also router redirects ports 1 and 2 to local addresses 192.168.0.2 and 192.168.0.3 respectively.

Problem is that when I am trying to connect to the sshd server on the virtual machine using dyndns address, that is, typing

ssh myaccount.dyndns.org -p 2 -l username

connection goes ok, but if I try typing

ssh myaccount.dyndns.org -p 1 -l username

connection times out:

$ ssh myaccount.dyndns.org -p 1 -l username
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to myaccount.dyndns.org [xxx.xxx.xxx.xxx] port 1.
debug1: connect to address xxx.xxx.xxx.xxx port 1: Connection timed out
ssh: connect to host myaccount.dyndns.org port 1: Connection timed out

Result is the same when I use PuTTY for windows. An interesting thing I noticed is that when I try pinging the dyndns address, result differs on the old pc and the FreeBSD virtual machine. For virtual machine:

$ ping myaccount.dyndns.org
PING myaccount.dyndns.org (xxx.xxx.xxx.xxx): 56 data bytes
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=0 ttl=64 time=1.638 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=0 ttl=63 time=1.669 ms (DUP!)
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=1 ttl=64 time=3.142 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=1 ttl=63 time=3.170 ms (DUP!)
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=2 ttl=64 time=2.599 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=2 ttl=63 time=2.633 ms (DUP!)
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=3 ttl=64 time=3.586 ms

--- myaccount.dyndns.org ping statistics ---
4 packets transmitted, 4 packets received, +3 duplicates, 0.0% packet loss
round-trip min/avg/max/stddev = 1.638/2.634/3.586/0.694 ms

and for old comp the same, but without DUPs. How may this problem be solved?

 

[izotov]

Does your solution want to be a home made NAT? So when SSHing to port 1 you are taken to the VM; when SSHing to port 2 you are taken to the phy FreeBSD. Is it? If so you probably should try to find a standard solution to this I think.

Anyway, I have lately seen such DUP replies and those happened when I pinged a multicast IPv6 address. So that meant that I got response from several places with the same address. If the same is the case for you it means something is not configured properly.

 

[SirDice]

Make sure the ssh daemon on both the host and the jail is bound to their IP address. By default it'll listen to all addresses. This can have strange results if both daemons listen to all addresses.

 

[_martin]

Where are you trying to connect from? Outside of the network or within?

If I did understand it correctly you want to be able to connect to both machines (physical FreeBSD and the virtual one) from outside of your network? Because if this is true, you don't need to do anything on either of the FreeBSD machines, i.e. both machines can listen on default port 22 (192.168.0.2:22 and 192.168.0.3:22 respectively).

The only difference is that you have to set the forwarding rules and NAT rules on your router. You enable that on the router and you are set. If you use ports "1" and "2" as you've described, you would enable forwarding rules as:

1 -> 192.168.0.2 port 22
2 -> 192.168.0.3 port 22

and you can connect to both of them using the syntax you mentioned in your post.

When you check dmesg or syslog output - can you see warnings about IP duplicities (ARP warnings)?