Slow SSH connection

[renatohtpc]

Migrating from ipcop to pfSense.

pfSense configuration
hostname: pfsense
domain: mynetwork.net

WAN - FIOS
LAN Network - 192.168.1.1 DHCP enabled
DMZ Network - 192.168.3.1 DHCP disabled

As I swapped the ipcop firewall with the pfSense and tried to ssh (from 192.168.1.74)  into one of the servers (192.168.3.6) on the DMZ, I noticed a significant lag in response (something like 10 secs before I got the prompt back to enter the password)

Here are some more details specific to the server on the DMZ:

/etc/hosts

Do not remove the following line, or various programs

that require network functionality will fail.

127.0.0.1      localhost      phone.mydomain.net phone localhost.localdomain localhost
::1            localhost6.localdomain6 localhost6

/etc/resolv.conf

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

/etc/sysconfig/networking/profiles/default/ifcfg-eth0

Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet

DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.3.255
HWADDR=AA:BB:CC:DD:EE:FF
IPADDR=192.168.3.6
NETMASK=255.255.255.0
NETWORK=192.168.3.0
ONBOOT=yes
GATEWAY=192.168.3.1
TYPE=Ethernet

Thank you
Renato

[hda]

You are adviced to stick to using the webgui for config and information sharing.

From where, what address, are you SSH-ing towards the DMZ ?

[renatohtpc]

I am connecting from 192.168.1.74.

Thanks
Renato

[kejianshi]

I also see a bit of a delay, but I blame it on the 8k miles of distance and the inherent latency of TCP.  (250-300 ping on some distant pfsense)

[renatohtpc]

In my case, the laptop is about 20 feet away from the server  :)

Also, the delay is not present with ipcop in place.

Thanks
Renato

[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.