• Migrating from ipcop to pfSense.

    pfSense configuration
    hostname: pfsense
    domain: mynetwork.net

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

    As I swapped the ipcop firewall with the pfSense and tried to ssh (from  into one of the servers ( 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:


    Do not remove the following line, or various programs

    that require network functionality will fail.      localhost      phone.mydomain.net phone localhost.localdomain localhost
    ::1            localhost6.localdomain6 localhost6


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


    Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet


    Thank you

  • 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


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


  • 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


  • 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: *
    Port: 53
    Gateway: *

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

    is this enough?


  • 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, is my PDC.

    Thanks again

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

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


  • 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 <== Verizon DNS1
    nameserver <== 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 from - 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 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.