Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSH logins slow - DNS?

I have been having an issue recently that I cannot figure out where the delay is sourced.

I have hosts configured to use the UTM as their DNS server, and have assigned the domain name suffix such that the utm is utm.best.example.com and the hosts are host1.best.example.com.  They have been assigned the best.example.com DNS suffix.  Everything talks fine.  nslookup works well and fast.  No perceptible delays.

However, now when I ssh to user@host1.best.example.com I have about a 3 second delay on getting prompted for my password.  It eventually works and the connection is speedy once established.

If I connect to user@ip.address it is very quick to prompt for password as it should be.

I have not changed any settings lately of which I am aware.  I have "UseDNS no" set in all of the sshd_config files and none of that has changed recently.

The debug of the ssh connection looks nearly identical between connecting via fqdn and ip address.  Something in the UTM is delaying things.

Is it possible that is it performing some sort of reputation lookups or something along those lines even though it is all local traffic?  I do not have another internal DNS server (home network), am not using AD, and have set the UTM to ignore the ISP dns and use OpenDNS for recursive lookups.  However, I have set all of the hosts in the UTM, so it should not be going out and they all resolve properly to internal addresses.

Please help me figure out how to troubleshoot.  I am definitely not new to systems admin and networking, but am still a little green on the UTM.

Yes, Bob, I have looked at the Rulz and haven't found anything interesting in the logs [:)].  And it is not traversing multiple interfaces, everything is on a local subnet.


This thread was automatically locked due to age.
Parents
  • Just a quick update:
    FIX
    I added "options single-request" to the resolv.conf file on my linux boxes and resolution is fast.
    EXPLANATION
    When sniffing the connections, I noticed that the client was performing a A query and AAAA query and it would not continue the connection until the AAAA query timed out.  I have IPv6 enabled on the clients but disabled on the UTM so I assumed that the UTM would respond with a NACK (or something to that effect) of a AAAA request.  It did not.  Thus, the delay.
Reply
  • Just a quick update:
    FIX
    I added "options single-request" to the resolv.conf file on my linux boxes and resolution is fast.
    EXPLANATION
    When sniffing the connections, I noticed that the client was performing a A query and AAAA query and it would not continue the connection until the AAAA query timed out.  I have IPv6 enabled on the clients but disabled on the UTM so I assumed that the UTM would respond with a NACK (or something to that effect) of a AAAA request.  It did not.  Thus, the delay.
Children
  • Just a quick update:
    FIX
    I added "options single-request" to the resolv.conf file on my linux boxes and resolution is fast.
    EXPLANATION
    When sniffing the connections, I noticed that the client was performing a A query and AAAA query and it would not continue the connection until the AAAA query timed out.  I have IPv6 enabled on the clients but disabled on the UTM so I assumed that the UTM would respond with a NACK (or something to that effect) of a AAAA request.  It did not.  Thus, the delay.


    I encountered the same problem, but would like to add some more details:
    In my scenario, both, DNS A and AAAA resolve fine on their own, but when ssh tries to connect and tries to resolve both at the same time, the AAAA request will time out. After the timeout, the AAAA request is repeated and resolves just fine.
    This happens only if APT-Protection or IPS is enabled on the UTM, wether I use an external DNS Server or the UTM itself.

    You can see the behaviour in the attached wireshark screenshot.

    The manpage for resolv.conf hints at similar problems:
                  single-request (since glibc 2.10)
                         sets  RES_SNGLKUP  in  _res.options.   By default, glibc performs IPv4 and IPv6 lookups in parallel since version 2.9.  Some appliance DNS servers cannot handle these queries properly and make the requests time out.  This option disables the behavior and makes glibc perform the IPv6 and IPv4 requests sequentially (at the cost of some slowdown of the resolving process).

    I would consider this a bug in the UTM that should be looked into.

    Edit:
    And it is already known: http://www.sophos.com/de-de/support/knowledgebase/117759.aspx

    ID30224 9.107 Parallel dns queries fail on identical source port
    ------------------------------------------------------------------------
    Description:  If more than one DNS request is sent on the same source
                  port 
                  in a very short timefranme it might happen in rare cases
                  that the request fails.
    Workaround:
    Fixed in:
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?