Slow SSH connection



  • 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



  • 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 ?



  • I am connecting from 192.168.1.74.

    Thanks
    Renato



  • 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)



  • 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



  • Are you using an IP to connect or a name?



  • 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



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



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

    I see DMZ DHCP disabled ???



  • 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



  • 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 ?



  • These are the rules I have.

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

    Thanks again
    Renato

    ![Orange Rules.jpg](/public/imported_attachments/1/Orange Rules.jpg)
    ![Orange Rules.jpg_thumb](/public/imported_attachments/1/Orange Rules.jpg_thumb)
    ![LAN Rules.jpg](/public/imported_attachments/1/LAN Rules.jpg)
    ![LAN Rules.jpg_thumb](/public/imported_attachments/1/LAN Rules.jpg_thumb)



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



  • 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



  • 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



  • 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…



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


  • LAYER 8 Global Moderator

    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.




  • @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 ?


  • LAYER 8 Global Moderator

    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.



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


Log in to reply