Slow SSH connection

[kejianshi]

Are you using an IP to connect or a name?

[renatohtpc]

I am using a FQDN (phone.mydomain.net).  Additionally I have created an alias in pfsense for phone.mydomain.net pointing to 192.168.3.6.

Thanks
Renato

[kejianshi]

I'd say there is perhaps a problem with DNS in that case.  Maybe its just resolving slow.

Try the same thing using the IP only and see if things speed up.

[hda]

Are local ICMP,  22 and 53 allowed for the local net ?
[Or total destination allowance] ?

I see DMZ DHCP disabled ???

[renatohtpc]

I have setup a rule for the DMZ:

Proto: IPv4 TCP/UDP
Source: DMZ net
Port: *
Destination: 192.168.1.1
Port: 53
Gateway: *

As for the LAN, I have 2 "wild card" rules for both IPv4* and IPv6* to any destination.

is this enough?

Thanks
Renato

[hda]

DMZ rules like that not only necessarily. I meant the wildcard rules for LAN, which you have. I assume the same for the DMZ.

I just saw the sparse SSHd config you posted. Allowance for your LAN numbers in sshd.conf ?

[renatohtpc]

These are the rules I have.

NOTE: Orange = DMZ
Also, 192.168.1.10 is my PDC.

Thanks again
Renato


[kejianshi]

So did you try with just IP or just assuming thats not it?

[renatohtpc]

I will try the IP approach first thing in the morning when my users (wife and daughters) are not online so that I can swap firewall :)

Thanks again
Renato

[renatohtpc]

OK, just tried SSH'ing into the server using the ip address. Same problem. About 20 secs lag time from entering username to being prompted for password.

Rebooted server and tried again using hostname and IP address.  Same results in both cases.

Thanks
Renato

[kejianshi]

How much processor does the server have?  And the client?  And bandwidth?  Is the crypto extremely heavy?

I will test mine now and tell you the time.

Maybe 3 seconds from beginning to end…

[hda]

Allow for ICMP local networks.
You could start broad experiment with giving the DMZ the comparable wildcard rules as your LAN.
Or otherwise with your few rules, see in log [Status: System logs: Firewall] what is happening.

[johnpoz]

search mydomain.net
nameserver 71.242.0.12 <== Verizon DNS1
nameserver 71.252.0.12 <== Verizon DNS2

So your pointing your ssh server to public dns then hitting it from private IP that it tries to do a PTR on I would assume..  So there could be delay there for sure.

So see attached image as example..  I started sniff on pfsense (which is where I point boxes too for dns)  I then hit 192.168.1.7 from 192.168.1.100 - you can clearly see the .7 box ask pfsense .253 (its dns) for the PTR of the IP that was logging in with ssh.  It my case pfsense answers, in your case I find it highly unlikely versizon dns knows about your rfc1918 address space ;)

I do believe you can turn it off with usedns no on your sshd box.  Or setup your sshd box to use something what can resolve your rfc1918 address space via PTR.

[hda]

@johnpoz:

…
So your pointing your ssh server to public dns then hitting it from private IP that it tries to do a PTR on I would assume..  So there could be delay there for sure.
...

Yeah that's a point, I judged mydomain.net as mydomain.local. But then I would assume DNS Resolver (localhost) could handle it before remote resolving ?.

So OP, is the pfSense not running a DNS or the DNS Forwarder ?

[johnpoz]

does not matter what your forward domain is be it public or not.. when you hit a ssh server its going to do a PTR for the IP that you came from.  If you connect from rfc1918 IP you better be pointing at a local dns that has the zones for your local IP ranges or your going to see a delay.

Unless you turn that feature off in ssh, which is the usedns no

It will still do dns but that should disable the PTR request.  Simple enough to validate with a sniff.

[kejianshi]

Yeah - Mine is using 128.0.0.1 locally and the root servers in unbound, so maybe thats why I'm not getting the huge delay.

At any rate, with such a big delay but without failure, I figured DNS must be involved.