Why would SSH via remote IP be faster than local IP?

Question

I have a Linux server running from my house, with a DynDNS URL setup pointing to my public IP address.

One of the things I've noticed is using the remote address such as url.dyn-dns.tv or my public IP connects faster to the server compared to my local 192.168.xx.xx.

Anyone have any ideas why this might be?

Answer 1

tl;dr Fix the DNS resolver configuration on the server. (a workaround is to turn off reverse lookups in SSHD but it is better to fix what is broken)

---

Original answer

Anyone have any ideas why this might be?

Not really but here's an anecdote that might help:

In the past, with a different protocol, when a connection takes unusually long to be established I have found that one cause is DNS timeouts as the server tries to lookup the name of an IP-address so it can record the client name in it's logs. If your client IP-address isn't properly known to the local DNS service and DNS isn't properly configured then the server can wait a long time for DNS to time-out.

The way to look for this sort of effect is to run network sniffers, initially at the client but also at the server, then you may be able to see some network traffic related to the connection, that takes a long time to get a response, or which gets no response (you may see retries)

tcpdump and wireshark are good.

---

Update 1

At the client with the delay in connecting

• find the client's IP address

  • On Windows, open a command prompt window and type ipconfig
  • On Linux, open a terminal window and type ifconfig -a

• optionally confirm you can speedily look up the server's IP-address

  • on windows nslookup servername
  • on Linux dig servername or host servername if your don't have dig.

At the server

• look up the name of the client
  • check in /etc/resolv.conf for the address of the first DNS nameserver
  • type dig -x 192.168.n.m @nameserver or host 192.168.n.m server where 192.168.n.m is replaced by the actual IP-address of the client and nameserver is the IP-address of the nameserver.
  • repeat for other nameservers listed in /etc/resolv.conf

the server should get a response in milliseconds. With a broken DNS config it will take several seconds to time out.

good config

# time host 192.168.3.4
Host 4.3.168.192.in-addr.arpa. not found: 3(NXDOMAIN)

real    0m0.130s
user    0m0.000s
sys     0m0.020s

bad config

# echo nameserver 1.2.3.4 > /etc/resolv.conf
# time host 192.168.3.4
;; connection timed out; no servers could be reached

real    0m10.010s
user    0m0.000s
sys     0m0.010s

Note the 10 second delay. That means any SSH service that wants to have client names in it's logs will take 10s to set up a SSH connection.

---

Update 2

It turns out this Q is (probably) an exact duplicate of Why does the "password" prompt take forever when I SSH into my Ubuntu 9.05 server?

---

Solution

Fix the DNS resolver configuration on the server.

Answer 2

I am going to guess that you are not running a local DNS so when the ssh server attempts to do a reverse DNS lookup it is waiting for a timeout. When you are connecting to the external address your are being NATted through an IP address that passes the DNS muster.

To turn off reverse DNS lookups you will have to edit your sshd_config file and find the line "UseDNS" and set it to "no". (You'll have to restart sshd for it to take effect.) Alternatively you can setup your own DNS server for your local subnet. (DNSMasq is a good lightweight one to play with if you don't want to mess with BIND)

Answer 3

You might try calling ssh with the maximal verbose option : ssh -v -v -v.
This might give some useful information.

One explanation I can think of is if your server is listening on iPv4 but you still have iPv6 enabled on your local system. The wait time would then be when ssh is trying in vain to access the server on iPv6, then gives up and tries iPv4 with success.

In any case, I suggest to verify which network adapters are enabled and disable the ones that are useless.