[c-nsp] Strange SSH lag with ACL applied

[Steve Bertrand]

Mikael Abrahamsson wrote:
> On Thu, 7 Jan 2010, Andy Saykao wrote:
> 
>> What I'm finding is that when I apply the ACL (VLAN2-FILTER-OUT ) to
>> VLAN2, it takes a very long time for the SSH login promtp to appear. If
>> I remove the ACL on VLAN2, the SSH prompt is instantaneous. What's going
>> on with my ACL??? Why the lag for the SSH prompt to appear?
> 
> The server is most likely doing an ident lookup, if you want to speed
> this up, make sure you don't silent-drop packets to 113/TCP to avoid this.

What SSH server software does this?

I was going to state that in all recent versions of OpenSSH (at least on
FreeBSD) one could change:

#UseDNS yes

...to:

UseDNS no

...in the /etc/ssh/sshd_config file.

Even though I've never done this change before, I have notified others
that the option is available.

My whole-hearted recommendation would be to configure forward and rDNS
for all hosts attempting to connect to the box. IPv6 inclusive.

Otherwise, the huge disheartening lag time is a non-subtle reminder that
the connecting host's DNS is fscked up.

If you are connecting from within RFC1918 space, it's internal, so fix it.

If it's v6, fix it, or contact your ISP to fix it (if you are an SSH
client trying to reach an SSH server on a remote network as an IPv6
client, in today's early v6 day-and-age, you *will* be able to find an
engineer that is v6-clueful).

If it is an IPv6 DNS resolution issue with your ISP-assigned addresses,
I will pretty much guarantee that they will be interested to learn about
the problem. They already have v6 deployed, and nobody has done so yet
without wanting and desiring feedback. If you feel that I am wrong in
the statements regarding IPv6, contact me privately.

It very well could be that the SSH server is trying to do a reverse
lookup on a residential client of an ISP that doesn't configure any rDNS
for its resi IP blocks whatsoever. In this case, contact your ISP, and
ask if they can  at least generate automated reverse entries for their
known 'dynamic' blocks. If they say no, ask why. If you get nothing, ask
for a static IP with an rDNS entry (some ISPs will only assign statics
at the /29 boundary. In cases of rDNS requirement, it may be worth
paying for it).

Port 113/TCP has nothing to do with this imho. This is a DNS issue that
can be resolved by the IP address supplier of the client, or at worst,
be fixed at server application level as specified above. I'm starting to
feel the dpi/hijacking anger sensation for some reason.

Perhaps someone will eventually create a global qinq (or its
technological equivalent) specifically for the revitalization of what
the Internet was meant to be ;)

...can we get back into ACL/firewall discussion now, I was thoroughly
enjoying what Roland has been saying. What he says is like very
expensive advise to the small net-ops who have never seen his hardware
in practice ;)

Steve